I need to persist the entire path taken by the client during the flow of the architect. We did some dataactions that send each action taken during the execution of the architect to a sqs queue, however, we are afraid that it will affect the speed that the client is served.
We thought about defining variables with the data of each action, however, in case there is a sudden disconnection, we would lose the data related to that connection.
Is there a way to trigger an event when there is a hangup?
When there was a hangup, the event would be triggered to send the data.
Or could you suggest some other solution?
You are correct that using many data actions will introduce delay. How much delay depends on the responsiveness of the service you're invoking. Another option would be to set participant data with the information you need. You can then post-process the data at a later time using Analytics Conversation Detail Jobs or you could design your flows to post the data via a data action at the end of the flow for both success and error conditions.
Additionally, you can request new features, such as detail IVR reporting, and share your use case at https://genesyscloud.ideas.aha.io/. Submitting your requests here helps us prioritize new features for the product.
Correct. Analytics queries do not contain participant data. See the link above for analytics jobs for a process that allows you to get participant data with analytics conversations.
We defined a code for every relevant IVR step creating a kind of IVR step catalog.
In the flow, whenever relevant we are setting/appending that code and a timestamp in a custom participant data attribute.
In the meantime there's a custom made daemon that keeps fetching conversations and parsing that attribute.
The parsed info is then stored on our client side in a database.
The catalog mentioned above also has the translation for every code, meaning, the description of every step in order to provide human readable reports fed from that database on the client side.
We are using the "realtime" api but like @tim.smith said, jobs are better suited because "realtime" conversation api only gives you data for 90 days (right @tim.smith ?) and also you might get in situation where you have to call api's more often and be overcharged by not complying with the fair api usage policy.