Flow publish failed using Cx as Code

Developer Tools
1

Hello,
I am trying to publish a Inqueue call flow using Cx as code but it fails with below message. The flow uses a Transfer to VoiceMail action.

Error: no matches -- [ArchAsyncTracker] type:Error] map[dateTime:2022-07-07T17:35:48.216Z text:setting the Archy exit code to 100 type:Error] map[dateTime:2022-07-07T17:35:48.869Z text:could not find the 'group' by name using the value 'CXaC_Group'.

I can confirm the group "CXaC_Group" is available in the org.

2

resource "genesyscloud_flow" "CXaC_InQueueFlow" {

depends_on = [

genesyscloud_auth_division.CXaC_Automation,

genesyscloud_group.CXaC_Group

]

filepath = "./flows/CXaC_InQueueFlow_flow.yaml"

substitutions = {

inqueue_flow_name = "CXaC_InQueueFlow"

division = genesyscloud_auth_division.CXaC_Automation.name

language     = "en-us"

voicemail_group = genesyscloud_group.CXaC_Group.name

}

}

resource "genesyscloud_group" "CXaC_Group" {

name = "CXaC_Group"

description = "Voice mail group"

type = "official"

visibility = "members"

rules_visible = true

owner_ids = [data.genesyscloud_user.roche.id]

member_ids = [data.genesyscloud_user.roche.id]

addresses {

number    = "7020"

type      = "GROUPRING"

extension = "7020"

}

}

Snippet that refers to the group name from the CXaC_InQueueFlow_flow.yaml file

  • transferToVoicemail:

                                    name: Transfer to Voicemail

                                destination:

                                  group:

                                    targetGroup:

                                      lit:

                                        name: "{{voicemail_group}}"
  • List item
3

Hi Roche,

Try using ${integration_category} instead {{voicemail_group}} in your YAML file. Archy uses a different mechanism for substitution than the CX as a Code flow component. I need to look at the code but I believe we are using GoLang's templating library which supports ${}.

Let me know if that works. If it does, I will open a ticket on our end to see if we can support ${} and {{}} in our substitution code because it would be nice to support both.

Thanks,
John Carnell
Manager, Developer Engagement

4

Hi John,
Thanks for your reply.
I still see the error after replacing it with ${}. Snippet from yaml file below.

  • transferToVoicemail:

                                    name: Transfer to Voicemail

                                destination:

                                  group:

                                    targetGroup:

                                      lit:

                                        name: ${voicemail_group}
5

Hi Roche,

A couple of things:

  1. Make sure the ${voicemail_group} is surround with " " quotes because it replaces the variable exactly as you expect it in the file.

  2. Most of the time when a resource fails it will log the correlation_id on the call that failed. If you have a correlation_id can you post it here?

  3. If you don't have a correlation id, can you turn on the sdk_debug at the provider level and then re-run the results and check the output logs. When I get the correlation id I can work with the flow dev team to figure out if the variable was injected into the flow properly.

  4. I suspect that this might be an eventual consistency problem. Sometimes group calls can take several seconds to propagate and if we are not waiting long enough or the group updates take too long we could be running into an issue. One way you could check is that after the call fails, run the exact terraform code again a minute later. If it succeeds, it is probably an eventual consistency problem.

Thanks for the patience as we work through this.
John Carnell
Manager, Developer Engagement

6
  • Make sure the ${voicemail_group} is surround with " " quotes because it replaces the variable exactly as you expect it in the file.

I tried with " " quotes as well but didn't work.

  • Most of the time when a resource fails it will log the correlation_id on the call that failed. If you have a correlation_id can you post it here?

JobID: faa482ec-9b5c-4cba-87dc-6a169f489781

  • If you don't have a correlation id, can you turn on the sdk_debug at the provider level and then re-run the results and check the output logs. When I get the correlation id I can work with the flow dev team to figure out if the variable was injected into the flow properly.
  • I suspect that this might be an eventual consistency problem. Sometimes group calls can take several seconds to propagate and if we are not waiting long enough or the group updates take too long we could be running into an issue. One way you could check is that after the call fails, run the exact terraform code again a minute later. If it succeeds, it is probably an eventual consistency problem.

I have used both groups: a) created via Cx as code in the same .tf file where the inqueue flow resource is dpresent. b) By creating a new group from Genesys UI directly. Doesn't appear to be eventual consistency problem

Thanks again for your help!

7

Hi Roche,

I am going to see if we can grab a copy of the flow passed into the service and then see if the substitution worked. That should give us some ideas of next steps.

Thanks,
John

8

Hi Roche,

I think we figured out what's going on. It is an eventual consistency problem, but not of the kind I thought it was. So here is what is happening:

  1. Our CX as Code resources will create resources (e.g. a group) and then continually ping the object API to see if the resource is readable. If it does not find the resource we will keep retrying until the object is readable. We do this in case the data for the object has been propagated across all of the DynamoDB amazon regions.

  2. So the group is created but here is where there is a disconnect. The architect flow gets uploaded, but the architect flow processor on the server-side uses our general search API (instead of the object-specific API) to search by name for the resources contained with the flow YAML file. If it can not find the resources via the search API it will fail and we think that is why you are seeing the error.

I am going to meet with my dev team on Monday so we can map out some possible fixes for this, but I don't have a timeline for the fix because of the time and effort involved in it. However, we do have a couple of workarounds:

  1. First, you can use do a look up of the queue by id inside of flow YAML instead of a look up by group name. Since, the group exists (it just has not been propagated to the search API yet). So instead of doing this:
  name: Transfer to Voicemail
                                destination:
                                  group:
                                    targetGroup:
                                      lit:
                                        name: "{{voicemail_group}}".  <-- Name being passed in

You could do some thing like this:

  name: Transfer to Voicemail
       destination:
           group:
              targetGroup:
                  lit:
                    id: "{{voicemail_group_id}}".  <-- You would pass in the GUID of the group that was created
  1. The second option is to build a wait of let's say 5-10 seconds right before you deploy your flow. To do this you would need to use the terraform time_sleep resource. You could set up something like this:
resource "time_sleep" "wait_10_seconds" {
  depends_on = [genesyscloud_auth_division.CXaC_Automation, genesyscloud_group.CXaC_Group]

  create_duration = "10s"
}

resource "genesyscloud_flow" "CXaC_InQueueFlow" {

depends_on = [
"wait_10_seconds" 

]
.....
}

This will put a 10s wait in front of the deployment of the flow.

Its not perfect, but it should get you around this problem until we can figure out a cleaner solution.

Thanks,
John Carnell
Manager, Developer Engagement

9

Thank you John. It worked after updating the name to GUID.

10

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.