ScottBub | 2017-02-10 22:23:24 UTC | #1
Hello,
We have downloaded and installed the bridge server and setup a custom action to query the database with a Service Order # that was entered into the call flow. A bridge action will send that SO# to the web service and the web service will query the DB. It will gather multiple details about the SO. Lets pretend that all the details returned by the DB are Boolean. (fields 1, 2, 3, 4, 5.)
When we receive the response how do those details get stored for us to utilize in our call flows? If we need to perform logic against each field returned (If field 1 is true, route the call like this, if field 2 is true route the call like this.)
I don't understand how it retains the information that was gathered from the web service for us to go back to the response several times and perform logic against the data in the response. Is it all in memory? Is there a secret database in the bridge server? Is the response automatically stored in the PureCloud call flow that triggered the bridge action to execute in some kind of pseudo-object?
tim.smith | 2017-02-13 16:47:26 UTC | #2
The results of the bridge action in Architect will be stored to whatever variables you specify for the outputs in the bridge action configuration. You can then use additional actions in Architect to make use of those variables. For more information, see the Resource Center article Use bridge actions in Architect for the web services data dip connector.
ScottBub | 2017-02-15 20:37:50 UTC | #3
I think I understand. So, when setting up the connector you are just providing the structure. The call flow task that you select to query the database is invoking that structure. You then define what items are used in this part of the call flow because it doesn't have to be all of them. Then, you perform each logical step based on all of the fields "variables" that you retrieved at the beginning of the task throughout the flow.
If you were to define a new task with a set of different steps in the same call flow, that would ultimately have to query the database again and use those variables. Is that correct?
As always, thank you for your guidance and expertise. The articles really do help along with your explanation.
tim.smith | 2017-02-15 21:12:34 UTC | #4
ScottBub, post:3, topic:906
If you were to define a new task with a set of different steps in the same call flow, that would ultimately have to query the database again and use those variables. Is that correct?
Task variables are scoped to a single task, so you cannot share task variables between tasks. However, you can share flow variables across all tasks in a flow. If you have a task variable, you can promote it to a flow variable. To do this, click on Data on the flow overview screen, found under the Resources heading. Click on the task variable you want to promote. Change the Variable Accessibility to Entire Flow and save it. The variable will now be available as Flow.varname instead of Task.varname.
Another way to share data is to use the Set Participant Data action to set the task variable data on the participant. This data will say with the participant throughout the life of the call (and for ~2 weeks after it ends) and can be accessed with the Platform API.
ScottBub | 2017-02-22 16:31:32 UTC | #5
Thank you, Tim. That makes a lot more sense now.
system | 2017-08-28 19:32:01 UTC | #6
This post was migrated from the old Developer Forum.
ref: 906