CX as Code: YAML substitutions in terraform genesys provider

[mfabrellas]

Hello,

I want to exemplify one of the main conflicts we are finding when managing flows using terraform with a simple case:

Modify a flow that will depend on a new resource:

• We have a resource1 for flow1 in our configuration.
• We want to create a new resource2 for queue2 and make resource1 depends on resource2 because flow1 will transfer to queue2
• We make these changes in our configuration:

1. Add resource2
2. In "depends_on" field from resource1 configuration we add resource 2
3. We modify flow1 YAML file so it calls queue2

• When we run terraform apply with these changes, we get an error. Terraform, before reading new dependencies, makes the "Refreshing state" action of resource1 to compare configuration with last state. When finds the modified flow1 calling a queue that does not exist (queue2 have not been created yet) it gives a "no matches" error, Archy exit code to 100.
• We think applying terraform with -refresh=false is not an option, is not a good practice and we had problems with this.
• The actual solution we found is to first create resource2 (queue2) without generating any dependencies in a first terraform run. And in a second run we create these dependencies in resource1 and modify flow1.
• This solution is not even possible when you add these dependencies in resource1 using substitutions feature and new variables in the YAML file. We would need a new resource to manage that modified flow.

In this simple case, where we only tried to change one flow, we needed to run terraform commands multiple times and change the configuration in between those runs.

In cases where we want to make a change in a flow which is called from other flows (e.g. changes at common modules or in-queue call flows or any flow that transfers to another) we would have to apply multiple and very complex changes in resources configurations while running terraform between each of them.

With my actual knowledge on this topic, this makes it very difficult to run terraform in automation through different environments without having duplicated configuration files for each environment.

If anyone is working on a similar use case and have some suggestions, it would be very helpful. Or if Genesys is working in their terraform provider with something that could solve these conflicts, it would be very useful to know about it.

Thanks for reading.

Miguel.

[charlie.conneely]

Hi Miguel,

Thanks for reporting - we'll take a look into this problem. If it is a bug, you should see a fix released in the coming weeks. And if we find any temporary work-arounds in the meantime, we'll let you know here.

Regards,
Charlie

[mfabrellas]

Thank you! @charlie.conneely

[John_Carnell]

Hi Miguel,

How are you managing your dependencies? From your description it sounds like you are making resource_2 depends_on resource_1 and then the flow dependent on resource_1. If that is the case that might be the problem. When Terraform runs it creates a dependency graph. If the flow is dependent on resource_1 and resource_1 has not changed then Terraform might think that it can run its changes in parallel.

If you have not done this make the flow call (with either the local-exec or the flow resource) dependent on resource_1 and resource_2. With my flows I always like to call out my flow dependencies with a depends_on defined right on the flow.

Let me know what you are doing. I am traveling today and potentially tomorrow, but I will try to check in on the forum to see your response.

Thanks,
John Carnell
Manager, Developer Engagement

[mfabrellas]

Hi John,

Thanks for your answer, I will show some code to clarify.

This would be the initial configuration for the example explained above with the following resource "project-1-flow" (resource_1):

resource "genesyscloud_flow" "project-1-flow" {
    filepath = "${path.module}/flows/project-1-flow.yaml"
    substitutions = {
        division = var.division
        default_language = var.default_language

        main_flow = var.main_flow
    }
}

And this would be the changes made to the initial configuration:
1 - Create a new queue "project-1-queue1" (resource_2)
2 - Make resource_1 depends_on resource_2

resource "genesyscloud_flow" "project-1-flow" {
    filepath = "${path.module}/flows/project-1-flow.yaml"
    substitutions = {
        division = var.division
        default_language = var.default_language

        main_flow = var.main_flow
        queue_name1 = var.P1_queue1
    }
    depends_on = [
        genesyscloud_routing_queue.project-1-queue1
    ]
}

resource "genesyscloud_routing_queue" "project-1-queue1" {
    name = var.P1_queue1
    division_id = var.division_id
    description              = "Queue to rout from Common Modules"
    acw_wrapup_prompt        = "OPTIONAL"
    auto_answer_only         = false
    skill_evaluation_method  = "ALL"
}

3 - Change YAML file "project-1-flow.yaml" and add this new action

- transferToAcd:
      name: Transfer to ACD
      targetQueue:
        lit:
          name: "{{queue_name1}}"
      preTransferAudio:
        tts: Hola
      failureTransferAudio:
        tts: Adios

When applying these changes and running again terraform commands, this is the error message that shows when trying to refresh:

genesyscloud_flow.project-1-flow: Refreshing state...

Error: Flow publish failed. JobID: b6a6bcc6-e252-4d64-ad68-dd399c669393, tracing messages: pre-processor substitution key of '{{queue_name1}}' was found in the flow YAML, but was not found in the options file.
│ find 'Queue' by value of '{{queue_name1}}' - no matches for '{{queue_name1}}' -- [ArchNetworkValueRetrieval]
│ 
│ promise unhandled exception caught.  Error: no matches -- [ArchAsyncTracker]
│
│ setting the Archy exit code to 100
│
│ could not find the 'queue' by name using the value '{{queue_name1}}'.
│ Error details: no matches
│     Path: '/inboundCall/tasks/task[New Task 1_12]/actions/transferToAcd[__archy_transferToAcd_2__]'
│     Property name: 'targetQueue'
│
│ Error(s) and warning(s) encountered.
│
│ Architect Scripting errors and warnings will be listed above.
│
│ exit code: 100

The problem is not in the dependencies, it is before, when refreshing the state of a modified flow with new dependencies, including new substitutions.

Thanks in advance,
Miguel.

[John_Carnell]

Hi Miguel,

Let me see if I can reproduce the problem in our lab. After rereading your email, my original answer did not make as much sense to me.

Thanks,
John

[mfabrellas]

Hi John.

Sure, thank you very much. It seems that the error occurs while it is refreshing the flow's state, before terraform shows the plan (for both commands: terraform plan and terraform apply).

Miguel.

[John_Carnell]

Hi Miguel,

Your question has certainly been interesting. While investigating this I finally figured out a subtle bug that another customer was reporting. I do not think this issue is a dependency issue. It has to do with how you are doing your variable substitution inside of your flow yaml file. Your flow yaml file has the name: "{{queue_name1}}"

- transferToAcd:
      name: Transfer to ACD
      targetQueue:
        lit:
          name: "{{queue_name1}}"
      preTransferAudio:
        tts: Hola
      failureTransferAudio:
        tts: Adios

This should be {{queue_name1}} with the surrounding quotes. Try changing that and let me know if that resolves the issues.

Thanks,
John Carnell
Manager, Developer Engagement

[mfabrellas]

Hi John,

If I understood properly what you meant in your answer, this does not resolve the issue, we use "{{queue_name1}}" in all our substitutions and it works. When I try {{queue_name1}} it gives me the following error:

│ Error: Flow publish failed. JobID: 53159ca9-227a-4c27-aefd-948c7f7dbb8d, tracing messages: setting the 
   Archy exit code to 100
│
│ expected a string but got a object value for:
│ [object Object]: null
│
│     Path: '/inboundCall/tasks/task[New Task 1_12]/actions/transferToAcd[__archy_transferToAcd_2__]'
│     Property name: 'targetQueue'
│
│ error(s) encountered.
│
│ exit code: 100

Maybe the queue dependency was not the best example to explain this issue. This issue appears every time we modify the YAML file and include new substitutions on it (adding to the "genesyscloud_flow" resource these new substitutions, that weren't known by the previous state).

Annother example with no dependencies, we have this configuration:

resource "genesyscloud_flow" "project-1-flow" {
    filepath = "${path.module}/flows/project-1-flow.yaml"
    substitutions = {
    division = var.division
    default_language = var.default_language

    main_flow = var.main_flow
    }
}

with this YAML file:

inboundCall:
  name: "{{main_flow}}"
  division: "{{division}}"
  startUpRef: "/inboundCall/tasks/task[New Task 1_12]"
  defaultLanguage: "{{default_language}}"
  supportedLanguages:
    es-us:
      defaultLanguageSkill:
        noValue: true
      textToSpeech:
        defaultEngine:
          voice: "es-US-Neural2-A"

To change the TTS voice trough a variable, we make the following changes to the configuration

resource "genesyscloud_flow" "project-1-flow" {
    filepath = "${path.module}/flows/project-1-flow.yaml"
    substitutions = {
    division = var.division
    default_language = var.default_language

    main_flow = var.main_flow

    tts-voice = "es-US-Neural2-B"
}

and to the YAML file

inboundCall:
  name: "{{main_flow}}"
  division: "{{division}}"
  startUpRef: "/inboundCall/tasks/task[New Task 1_12]"
  defaultLanguage: "{{default_language}}"
  supportedLanguages:
    es-us:
      defaultLanguageSkill:
        noValue: true
      textToSpeech:
        defaultEngine:
          voice: "{{tts-voice}}"

Now, when we try to run terraform (during the refreshing process) we get the same error I was showing in my previous messages.

│ Error: Flow publish failed. JobID: 1aae6722-d857-4831-a3ef-2b73b757d7e3, tracing messages: pre-processor substitution key of '{{tts-voice}}' was found in the flow YAML, but was not found in the options file.

Thank you,
Miguel.

[John_Carnell]

Hi Miguel,

A couple of things:

1. I do believe the extra quotes were causing your initial issue as I was able to reproduce it immediately. Some of the values require " " around values and other do not.
2. Your initial problem uncovered a bug that has been in hiding in the flow provider since we released it 6 months ago. The bug basically will not properly handling substitutions when a YAML file changes (not just the substitutions). So if you deploy a flow and then change it and then add/change a substitution, the substitution will not be properly sent to the file. All of our test cases do substitution changes and never change or touch the YAML file. I have fixed the bug and updated or test cases.

The code is up for PR right now. Once we get through code review we will get it merged and then published. The target date will hopefully be either tomorrow or Tuesday.

If you are blocked you can:

1. You can deploy using a local-exec and the archy cli inside of CX as Code.
2. You can download the branch source and compile the branch locally. Instructions for building locally can be found here
   resolves the issue.

[mfabrellas]

Hi John,

Thank you for the information and your fast response, it is very helppful. As soon as we try it, we will let you know our feedback in here.

Regards,
Miguel.

[John_Carnell]

Hi Miguel,

Thanks for your patience. While CX as Code is open source, we do want to be as responsive as possible when issues arise. I am going to drop a dev forum announcement once the code has been released.

Thanks,
John

[John_Carnell]

Hi Miguel,

The CX as Code v1.8.0 provider was published on Friday with fixes that should hopefully solve your problem with the substituted variables. Please let me know if you are still having issues.

Thanks,
John Carnell
Manager, Developer Engagement

[mfabrellas]

Hi John,

I've been trying the new provider version with some use cases in which we were affected by this issue and now it seems to work perfectly, If we find any other anomalies we will let you know. Thank you for the great job.

Regards,
Miguel.

[John_Carnell]

Hi Miguel,

Excellent! Glad our fixed worked. In the end the problem came down to how we were handling variable substitution and what happened when variable substitution occurred after the YAML file had been modified. As most bugs, it took forever to find the issue and seconds to fix. Thanks again for the patience and keep the feedback coming.

Thanks,
John Carnell
Manager, Developer Engagement