Genesys Documentation - User contributions [en]

RN/VoiceVoicemail Service/100.0.100.0030

2024-01-03T07:09:24Z

MPandian: Published

{{ComponentRN
|ComponentId=aaceaac0-cfa6-437f-9c8a-30b57f9d802e
|JQL=labels=VMCSVSRN10001000030
|DeploymentTypeId=5439f1be-1868-4091-b058-1667389b6ce1
|ReleaseDate=2023-12-20
|Highlight=Resolved issue.
}}
{{Issue
|TicketNumber=VOICEMCS-5887
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=Voicemail access of a mailbox with local 'fr' should not fail while accessing voicemail message deposited from a caller number which is greater than or equal to 5 characters length, There should not be any pod crash
|LocalContent=Voicemail access of a mailbox with locale set to <code>fr</code> no longer fails while accessing voicemail message submitted by a caller number which is greater than or equal to 5 characters in length. Previously, such scenarios caused a pod crash.
}}

Draft:RN/VoiceRegistrar Service/100.0.100.0028

2023-07-17T16:10:58Z

MPandian: MPandian moved page Draft:RN/VoiceRegistrar Service/100.0.100.0028 to Draft:RN/VoiceRegistrar Service/100.0.100.0029

#REDIRECT [[Draft:RN/VoiceRegistrar Service/100.0.100.0029]]

RN/WebRTCMedia Service/100.0.072.0000

2023-06-21T19:51:44Z

MPandian: Published

{{ComponentRN
|ComponentId=0371606b-df5e-41e2-869d-2009e76b916e
|JQL=labels=WebRTCRN10000690000
|DeploymentTypeId=ec194bf2-b79a-436d-8ff6-eaff94d9f43a, 5439f1be-1868-4091-b058-1667389b6ce1
|ReleaseDate=2023-06-20
|ReleaseNumber=100.0.072.0000
|Highlight=*New traces for ICE failures.
*Resolved issues.
}}
{{Issue
|TicketNumber=WRTCMS-1278
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=Previously, WebRTC Gateway incorrectly handled responses from GWS Configuration Service if “Content-length“ header in lower case.Now, “Content-length“ header in lower case is processed correctly.
}}
{{Issue
|TicketNumber=WRTCMS-1273
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=Log messages from different threads interrupts each other because of \r\n in SIP or other messages and one single message takes few lines.Now in case of output of logs into stdout these chars \r and \n are escaped and multiline messages take single line
}}
{{Issue
|TicketNumber=WRTCMS-1218
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=WebRTC Gateway metrics were reworked and new tenant dimension was added to tenant-related metrics
}}
{{Issue
|TicketNumber=WRTCMS-1214
|IssueCategoryId=720446c8-10b6-42b8-af36-34a298aa1c72
|Content=New traces are added for case if ICE failure "SYS", "ICEFailed", "ICE State moved to FAILED, remote candidates are present""SYS", "ICEFailed", "ICE State moved to FAILED, no remote candidates""SYS", "ICEFailed", "ICE Failed during established connection"Also new metric is added for ICE failed case:wrtc_system_errors{ type="failedice" }
}}
{{Issue
|TicketNumber=WRTCMS-1178
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=Now, in case of SIP registration failure. webrtc gateway will not drop active call but preserve RTP stream to allow agent continue to talk with customer.
}}
{{Issue
|TicketNumber=WRTCMS-1280
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
}}
{{Issue
|TicketNumber=WRTCMS-1281
|IssueCategoryId=720446c8-10b6-42b8-af36-34a298aa1c72
}}
{{Issue
|TicketNumber=WRTCMS-1297
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
}}
{{Issue
|TicketNumber=WRTCMS-1298
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
}}
{{Issue
|TicketNumber=WRTCMS-1302
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
}}
{{Issue
|TicketNumber=WRTCMS-1310
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
}}

RN/WebRTCMedia Service/100.0.072.0000

2023-06-21T18:57:25Z

MPandian: Published

{{ComponentRN
|ComponentId=0371606b-df5e-41e2-869d-2009e76b916e
|JQL=labels=WebRTCRN10000690000
|DeploymentTypeId=ec194bf2-b79a-436d-8ff6-eaff94d9f43a, 5439f1be-1868-4091-b058-1667389b6ce1
|ReleaseDate=2023-06-20
|ReleaseNumber=100.0.072.0000
}}
{{Issue
|TicketNumber=WRTCMS-1278
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=Previously, WebRTC Gateway incorrectly handled responses from GWS Configuration Service if “Content-length“ header in lower case.Now, “Content-length“ header in lower case is processed correctly.
}}
{{Issue
|TicketNumber=WRTCMS-1273
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=Log messages from different threads interrupts each other because of \r\n in SIP or other messages and one single message takes few lines.Now in case of output of logs into stdout these chars \r and \n are escaped and multiline messages take single line
}}
{{Issue
|TicketNumber=WRTCMS-1218
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=WebRTC Gateway metrics were reworked and new tenant dimension was added to tenant-related metrics
}}
{{Issue
|TicketNumber=WRTCMS-1214
|IssueCategoryId=720446c8-10b6-42b8-af36-34a298aa1c72
|Content=New traces are added for case if ICE failure "SYS", "ICEFailed", "ICE State moved to FAILED, remote candidates are present""SYS", "ICEFailed", "ICE State moved to FAILED, no remote candidates""SYS", "ICEFailed", "ICE Failed during established connection"Also new metric is added for ICE failed case:wrtc_system_errors{ type="failedice" }
}}
{{Issue
|TicketNumber=WRTCMS-1178
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=Now, in case of SIP registration failure. webrtc gateway will not drop active call but preserve RTP stream to allow agent continue to talk with customer.
}}
{{Issue
|TicketNumber=WRTCMS-1280
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
}}
{{Issue
|TicketNumber=WRTCMS-1281
|IssueCategoryId=720446c8-10b6-42b8-af36-34a298aa1c72
}}
{{Issue
|TicketNumber=WRTCMS-1297
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
}}
{{Issue
|TicketNumber=WRTCMS-1298
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
}}
{{Issue
|TicketNumber=WRTCMS-1302
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
}}
{{Issue
|TicketNumber=WRTCMS-1310
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
}}

RN/Designer/100.0.208.0017

2023-05-23T08:42:52Z

MPandian: Published

{{ComponentRN
|ComponentId=b9e5e9d4-37a0-4fa2-87a3-957773249c9b
|JQL=labels=DESRN10002080017
|DeploymentTypeId=ec194bf2-b79a-436d-8ff6-eaff94d9f43a, 5439f1be-1868-4091-b058-1667389b6ce1
|ReleaseDate=2023-05-23
}}
{{Issue
|TicketNumber=DES-14180
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=Amazon Lex and Dialogflow ES bot integrations that do not have *Use Streaming Audio* enabled in the Bot Block now function as expected (DES-14180)
|LocalContent=Amazon Lex and Dialogflow ES bot integrations that do not have '''Use Streaming Audio''' enabled in the Bot block now function as expected.
}}
{{Issue
|TicketNumber=DES-13848
|IssueCategoryId=720446c8-10b6-42b8-af36-34a298aa1c72
|Content=A new function isLiveStream() has been added in Designer which a returns a boolean value of true indicating the current interaction is executing on Live or Live_B streams or false otherwise. This is a more reliable way to distinguish between live and non-live traffic to make decisions than using the undocumented “stream” userdata Key-Value Pair.
|LocalContent=A new function, '''isLiveStream(),''' is added in Designer. It a returns a boolean value of ''true'' indicating that the current interaction is executing on Live or Live_B streams or ''false'' otherwise. This is a more reliable way to distinguish between live and non-live traffic to make decisions than using the undocumented <code>stream</code> userdata Key-Value Pair.
}}
{{Issue
|TicketNumber=DES-13649
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=The Standard Response UI in Designer no longer generates an error when inserting Field Codes in the Content section.
|LocalContent=The Standard Response UI in Designer no longer generates an error when inserting Field Codes in the Content section.
}}

RN/GenesysPulse/100.0.000.0020

2022-11-14T14:26:32Z

MPandian: Published

{{ComponentRN
|ComponentId=6e3d490b-bb6c-4e5d-8a61-313290c6d632
|JQL=project = WBRT AND fixVersion = 100.0.000.0020 AND "Release Note[Paragraph]" is not EMPTY order by created DESC
|DeploymentTypeId=5439f1be-1868-4091-b058-1667389b6ce1
|ReleaseDate=2022-11-14
|Highlight=Updates to the User Permissions service add new monitoring options and improved performance.

Security enhancements.
}}
{{Issue
|TicketNumber=WBRT-17235
|IssueCategoryId=c749afa5-fd21-49e4-83d4-0e6ebd8ed618
|Content=*Security:*3rd party libraries update for security remediation: {{CVE-2022-42004}}, {{CVE-2022-42003}}, {{CVE-2022-25857}} and others.
|LocalContent=3rd party libraries were updated to provide security remediation for various issues, including: [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42004 CVE-2022-42004], [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42003 CVE-2022-42003], and [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25857 CVE-2022-25857].
}}
{{Issue
|TicketNumber=WBRT-17212
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=*Known Issue*Template change propagation may fail if there is a Pulse user that was removed from configuration and added back with the same username.*Corrections and modifications*Pulse now handles correctly situation when there is a Pulse user that was removed from configuration and added back with the same username.
|LocalContent=Pulse now behaves correctly when a Pulse user that was removed from the configuration is added back with the same username. Previously, the template change propagation may fail in this scenario.

 
}}
{{Issue
|TicketNumber=WBRT-17149
|IssueCategoryId=720446c8-10b6-42b8-af36-34a298aa1c72
|Content=*Performance:*User Permissions service performance improvements.
|LocalContent=The User Permissions service includes new performance improvements.
}}
{{Issue
|TicketNumber=WBRT-17083
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|Content=*Known Issue*In some cases Widget Template change propagation could fail due to deadlock that happens in batch widget update performed in the same transaction.*Correction and modification*Widget Template change propagation now updates widgets separately that helps to avoid deadlocks.
|LocalContent=Changes to the Widget Template are now propagated to widgets separately, avoiding any potential deadlocks that could occur during a batch widget update.
}}
{{Issue
|TicketNumber=WBRT-15142
|IssueCategoryId=720446c8-10b6-42b8-af36-34a298aa1c72
|Content=*Monitoring*Improved User Permissions service monitoring now enables status of connection to DB, Redis and CSP, number of active users, latency and cache utilisation.
|LocalContent=Improvements to the User Permissions service now allow you to monitor the following: status of connection to the database, status of connection to Redis and CSP, number of active and inactive users, and latency and cache utilization.
}}

RN/GenesysPulse/100.0.000.0016

2022-11-14T14:26:25Z

MPandian: Published

{{ComponentRN
|ComponentId=6e3d490b-bb6c-4e5d-8a61-313290c6d632
|JQL=Issue = WBRT-17093
|DeploymentTypeId=5439f1be-1868-4091-b058-1667389b6ce1
|ReleaseDate=2022-10-20
|PrivateEditionReleaseDate=2022-10-20
|Highlight=Security enhancements.
}}
{{Issue
|TicketNumber=WBRT-17093
|IssueCategoryId=c749afa5-fd21-49e4-83d4-0e6ebd8ed618
|Content=Security Enhancements — This release includes security fixes in the base images to remediate various non-exploitable vulnerabilities.
|LocalContent=This release includes security fixes in the base images to remediate various non-exploitable vulnerabilities.
}}
{{Issue
|TicketNumber=WBRT-17212
|IssueCategoryId=7677e764-86f7-44e3-92bc-f13b59c71260
|LocalContent=Template change propagation may fail if there is a Pulse user that was removed from configuration and added back with the same username.
}}
{{Issue
|TicketNumber=WBRT-17083
|IssueCategoryId=7677e764-86f7-44e3-92bc-f13b59c71260
|LocalContent=In some cases, Widget Template change propagation could fail due to a deadlock that occurs in a batch widget update performed in the same transaction.
}}

RN/Recording QM and Interaction Analytics/8.5.512.34

2022-10-20T12:19:02Z

MPandian: Published

{{ComponentRN
|ComponentId=c6d90412-17a5-4d3b-b822-060c75731775
|JQL=issuekey in (PRSM-28856)
|DeploymentTypeId=5439f1be-1868-4091-b058-1667389b6ce1
|ReleaseDate=2022-10-09
|Highlight=Includes support for SMS interaction and resolved issues.
}}
{{Issue
|TicketNumber=PRSM-28856
|IssueCategoryId=720446c8-10b6-42b8-af36-34a298aa1c72
|Content=SpeechMiner now supports processing of SMS interactions. You can now filter, evaluate, and create a report for these interactions.
|LocalContent=SpeechMiner now supports processing of SMS interactions. You can now filter, evaluate, and create a report for these interactions.
|SupportingDocumentation={{Link-AnywhereElse|product=PEC-REC|version=Current|manual=User|topic=createanewsearch|anchor=interaction-properties}}
}}
{{Issue
|TicketNumber=WFOAZURE-2113
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|LocalContent=A search performed with more than one term in the search filter now returns the required interactions. Previously, the search performed with multiple terms didn’t return any interactions.
}}
{{Issue
|TicketNumber=WFOAZURE-1971
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|LocalContent=If a topic has terms with a single word, then the single word term is now recognized only as a complete word and not as part of other words. For example, the term “age" doesn’t recognize and match the words such as “coverage”, ”package”, and so on. Previously, the single word term in the topic recognized similar terms even if the term was part of the words.
}}
{{Issue
|TicketNumber=WFOAZURE-1903
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|LocalContent=When a digital interaction has only an open HTML tag and the text content type is not set to HTML, the text after the open HTML tag now appears in the UI. Also, if the custom tag is within the HTML tag, and if the text content type is not set to HTML, the custom tag now appears in the UI. Previously, in such scenarios, the text after the open HTML tag and the custom tag didn’t appear in the UI.
}}
{{Issue
|TicketNumber=PRSM-28895
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|LocalContent=The metadata fields for the '''Metadata Frequency''' report now appear in alphabetical order.
}}
{{Issue
|TicketNumber=PRSM-28844
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|LocalContent=SpeechMiner now displays the system recorded or automated or IVR segments of an interaction with a new icon in the '''Transcription''' section.
}}
{{Issue
|TicketNumber=PRSM-28818
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|LocalContent=Free Form answer can now handle up to 4000 characters. Previously, Free Form supported only up to 2000 characters.
}}
{{Issue
|TicketNumber=WFOAZURE-2193
|IssueCategoryId=7677e764-86f7-44e3-92bc-f13b59c71260
|LocalContent=If your '''Free form''' answer has 4000 characters, the last character in the '''Free form''' answer does not appear when you export it to PDF.
}}
{{Issue
|TicketNumber=PRSM-28644
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|LocalContent=If an interaction is sent with multiple segments tagged to different programs, the whole interaction is now tagged to the latest program and the search no longer fails.
}}
{{Issue
|TicketNumber=WFOAZURE-2035
|IssueCategoryId=5c483167-c133-4dc5-87c0-bd2719670bc1
|LocalContent=The '''Usage Tracking''' report execution is now optimized to improve its performance.
}}
{{Issue
|TicketNumber=PRSM-28836
|IssueCategoryId=720446c8-10b6-42b8-af36-34a298aa1c72
|LocalContent=Interaction metadata that are marked as key metadata items now appear on top of the form in an evaluation session in ''key:value'' pairs.
}}
{{Issue
|TicketNumber=WFOAZURE-2195
|IssueCategoryId=7677e764-86f7-44e3-92bc-f13b59c71260
|LocalContent=When an evaluation is exported to PDF, '''Free form''' answer is displayed after a blank page and the first line of the answer is not aligned properly.
}}

Template:IncludedServiceUpgradeStrategy

2022-05-20T10:11:15Z

MPandian: Created page with "<noinclude> This is the "IncludedServiceUpgradeStrategy" template. It should be called in the following format: <pre> {{IncludedServiceUpgradeStrategy |IncludedServiceUpgradeS..."

<noinclude>
This is the "IncludedServiceUpgradeStrategy" template.
It should be called in the following format:
<pre>
{{IncludedServiceUpgradeStrategy
|IncludedServiceUpgradeStrategy=
|IncludedServiceUpgradeStrategyName=
|IncludedServiceId=
|Notes=
}}
</pre>
Edit the page to see the template text.
{{#cargo_declare:_table=IncludedServiceUpgradeStrategy|IncludedServiceUpgradeStrategy=String|IncludedServiceUpgradeStrategyName=String|IncludedServiceId=String|Notes=Wikitext(1000)}}
</noinclude><includeonly>{{#cargo_store:_table=IncludedServiceUpgradeStrategy|IncludedServiceUpgradeStrategy={{{IncludedServiceUpgradeStrategy|}}}|IncludedServiceUpgradeStrategyName={{#cargo_query:tables=UpgradeStrategy|fields=StrategyName|where=Id HOLDS {{{IncludedServiceUpgradeStrategy|}}}}}|IncludedServiceId={{{IncludedServiceId|}}}|Notes={{{Notes|}}} }}</includeonly>

<noinclude>[[Category:PrivateEdition]]</noinclude>

User:MPandian

2022-04-25T19:22:42Z

MPandian:

My user page on MintyDocs!

Testing.

{{#dpl:
|namespace=Template
|titlematch=GCXI%%
|resultsheader=%PAGES% templates
}}

DES/Current/DESPEGuide/Deploy

2022-03-28T08:34:57Z

MPandian: Published

{{Article
|Standalone=No
|DisplayName=Deploy Designer
|Context=Learn how to deploy Designer. This topic explains the deployment process for Designer and DAS.
|ComingSoon=No
|Section={{Section
|sectionHeading=Preparation
|anchor=prep
|alignment=Vertical
|structuredtext={{NoteFormat|Review the {{Link-SomewhereInThisVersion|topic=Planning}} topic for the full list of prerequisites required to deploy Designer.|}}

Before you deploy Designer and DAS using Helm charts, complete the following preparatory steps:

#Ensure the Helm client is installed.
#Set up an Ingress Controller, if not already done.
#Setup an NFS server, if not already done.
#Create Persistent Volumes - a sample YAML file is provided in the Designer manifest package.
#Download the Designer and DAS docker images and push to the local docker registry.
#Download the Designer package and extract to the current working directory.
#Configure Designer and DAS value overrides ('''designer-values.yaml''' and '''das-values.yaml'''); ensure the mandatory settings are configured. If the Blue-Green deployment process is used, Ingress settings are explained in the {{Link-SomewhereInThisVersion|manual=DESPEGuide|topic=Deploy|display text=Blue-Green deployment}} section.
{{NoteFormat|Depending on the Kubernetes platform or the container orchestration platform that you are deploying Designer on, you might have to carry out some additional steps specific to that platform. For more information, navigate to the required topic in the '''Kubernetes platform specific information''' section on the {{Link-SomewhereInThisVersion|manual=DESPEGuide|display text=About}} page.|}}
===Set up Ingress===
Given below are the requirements to set up an Ingress for the Designer UI:

*Cookie name - designer.session.
*Header requirements - client IP & redirect, passthrough.
*Session stickiness - enabled.
*Allowlisting - optional.
*TLS for ingress - optional (should be able to enable or disable TLS on the connection).

===Set up Application Gateway (WAF) for Designer===
Designer Ingress must be exposed to the internet using Application Gateway enabled with WAF.

When WAF is enabled, consider the following exception in the WAF rules for Designer:

*Designer sends a JSON payload with data, for example, <code>{profile . {} }</code>. Sometimes, this is detected as <code>OSFileAccessAttempt</code>, which is a false positive detection. Disable this rule if you encounter a similar issue in your WAF setup.

===Storage===
====Designer storage====
Designer requires storage to store designer application workspaces. Designer storage is a shared file storage that will be used by the Designer and DAS services.{{NoteFormat|This storage is critical. Ensure you take backups and snapshots at a regular interval, probably, each day.|}}A Zone-Redundant Storage system is required to replicate data from the RWX volumes and must be shared across multiple pods:

*Capacity - 1 TiB
*Tier - Premium
*Baseline IO/s - 1424
*Burst IO/s - 4000
*Egress Rate - 121.4 MiBytes/s
*Ingress Rate - 81.0 MiBytes/s

====DAS storage====
If the Designer workspace is stored in a cloud storage system such as Azure Files, then the data must be synced to the DAS pods using the Designer-Sync service. In this case, DAS must use the <code>StatefulSet</code> deployment type. In the DAS StatefulSet pods, each pod must be attached to a premium SSD disk to store the workspace.

*Size - > 500GiB
*Max IOPS (Max IOPS w/ bursting) - 2,300 (3,500)
*Max throughput (Max throughput w/ bursting) - 150 MB/second (170 MB/second)

====Permission considerations for Designer and DAS storage====
'''NFS'''

For NFS RWX storages, the mount path should be owned by <nowiki><code>genesys:genesys</code></nowiki>, that is, <nowiki><code>500:500</code></nowiki> with <nowiki><code>0777</code></nowiki> permissions. It can be achieved by one of the below methods:

*From the NFS server, execute the '''chmod -R 777 <export_path>''' and '''chown -R 500:500''' '''<export_path>''' commands to set the required permissions.
*Create a dummy Linux based pod that mounts the NFS storage. From the pod, execute the '''chmod -R 777 <mount_path>''' and '''chown -R 500:500 <mount_path>''' commands. This sets the required permissions. However, this method might require the Linux based dummy pods to be run as privileged pods, that is, as root.

'''SMB / CIFS'''

For SMB / CIFS based RWX storages, for instance, Azure file share, the below <code>mountOptions</code> must be used in the '''StorageClass''' or the '''PersistentVolume''' template using the <code>designer.volumes.workspacePv.mountOptions</code> helm values. The <code>mountOptions</code> can also be used with the storage class template though it is not recommended.

'''Kubernetes clusters'''

Usually, the Designer and DAS pods are run with UID and GID as 500.

'''<code>mountOptions</code>'''<syntaxhighlight>
- dir_mode=0777
- file_mode=0777
- uid=500
- gid=500
- mfsymlinks
- cache=strict
</syntaxhighlight>
'''OpenShift clusters'''

In OpenShift, where you can use an arbitrary UID, the UID and GID in <code>mountOptions</code> should be replaced with the UID assigned to the project in OpenShift and GID should be 0.

'''<code>mountOptions</code>'''

<source>
- dir_mode=0777
- file_mode=0777
- uid=<random_uid_of_the_project>
- gid=0
- mfsymlinks
- cache=strict</source>
===Set up Secrets===
Secrets are required by the Designer service to connect to GWS and Redis (if you are using them).

GWS Secrets:

*GWS provides a Client ID and secrets to all clients that can be connected. You can create Secrets for the Designer client as specified in the ''Set up secrets for Designer'' section below.

Redis password:

*If Designer is connected to Redis, you must provide the Redis password to Designer to authenticate the connection.

====Set up Secrets for Designer====
Use the <code>designer.designerSecrets</code> parameter in the '''values.yaml''' file and configure Secrets as follows:

<source>designerSecrets:
enabled: true
secrets:
DES_GWS_CLIENT_ID: xxxx
DES_GWS_CLIENT_SECRET: xxxx
DES_REDIS_PASSWORD: xxxxx</source>
|Status=No
}}{{Section
|sectionHeading=Deployment strategies
|anchor=depstrats
|alignment=Vertical
|structuredtext=Designer supports the following deployment strategies:

*Rolling Upgrade (default).
*Blue-Green (recommended).

DAS (Designer Application Server) supports the following deployment strategies:

*Rolling Upgrade (default).
*Blue-Green (recommended).
*Canary (must be used along with Blue-Green and is recommended in production).
|Status=No
}}{{Section
|sectionHeading=Rolling Upgrade deployment
|anchor=rollupdep
|alignment=Vertical
|structuredtext=The rolling deployment is the standard default deployment to Kubernetes. It works slowly, one by one, replacing pods of the previous version of your application with pods of the new version without any cluster downtime. It is the default mechanism of upgrading for both Designer and DAS.
===Designer===
====Initial deployment====
To perform the initial deployment for a rolling upgrade in Designer, use the Helm command given below. The values.yaml file can be created as required.

*<code>helm upgrade --install designer -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.image.tag=9.0.1xx.xx.xx</code>

The values.yaml overrides passed as an argument to the above Helm upgrade command:

<code>designer.image.tag=9.0.1xx.xx.xx</code> - This is the new Designer version to be installed, for example, <code>9.0.111.05.5</code>.

====Upgrade====
To perform an upgrade, the image version has to be upgraded in the '''designer-values.yaml''' file or can be set using the <code>--set</code> flag through the command given below. Once the '''designer-values.yaml''' file is updated, use this Helm command to perform the upgrade:

*<code>helm upgrade --install designer -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.image.tag=9.0.1xx.xx.xx</code>

The values.yaml overrides passed as an argument to the above Helm upgrade command:

<code>designer.image.tag=9.0.1xx.xx.xx</code> - This is the new Designer version to be installed, for example, <code>9.0.111.05.5</code>.

====Rollback====
To perform a rollback, the image version in the '''designer-values.yaml''' file can be downgraded. Or you can use the <code>--set</code> flag through the command given below. Once the '''designer-values.yaml''' file is updated, use this Helm command to perform the rollback:

*<code>helm upgrade --install designer -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.image.tag=9.0.1xx.xx.xx</code>

The values.yaml overrides passed as an argument to the above Helm upgrade command:

<code>designer.image.tag=9.0.1xx.xx.xx</code> - This is the Designer version to be rolled back to, for example, <code>9.0.111.05.5</code>.

===DAS===

====Initial deployment====
To perform the initial deployment for a rolling upgrade in DAS, use the Helm command given below. The values.yaml file can be created as required.

*<code>helm upgrade --install designer-das -f designer-das-values.yaml designer-das-100.0.112+xxxx.tgz --set das.image.tag=9.0.1xx.xx.xx</code>

The values.yaml overrides passed as an argument to the above Helm upgrade command:

<code>das.image.tag=9.0.1xx.xx.xx</code> - This is the new DAS version to be installed, for example, <code>9.0.111.05.5</code>.

====Upgrade====
To perform an upgrade, the image version has to be upgraded in the '''designer-das-values.yaml''' file or can be set using the <code>--set</code> flag through the command given below. Once the '''designer-das-values.yaml''' file is updated, use this Helm command to perform the upgrade:

*<code>helm upgrade --install designer-das -f designer-das-values.yaml designer-das-100.0.112+xxxx.tgz --set das.image.tag=9.0.1xx.xx.xx</code>

The values.yaml overrides passed as an argument to the above Helm upgrade command:

<code>das.image.tag=9.0.1xx.xx.xx</code> - This is the new DAS version to be installed, for example, <code>9.0.111.05.5</code>.

====Rollback====
To perform a rollback, the image version in the '''designer-das-values.yaml''' file can be downgraded. Or you can use the <code>--set</code> flag through the command given below. Once the '''designer-das-values.yaml''' file is updated, use this Helm command to perform the rollback:

*<code>helm upgrade --install designer-das -f designer-das-values.yaml designer-das-100.0.112+xxxx.tgz --set das.image.tag=9.0.1xx.xx.xx</code>

The values.yaml overrides passed as an argument to the above Helm upgrade command:

<code>das.image.tag=9.0.1xx.xx.xx</code> - This is the DAS version to be rolled back to, for example, <code>9.0.111.05.5</code>.
|Status=No
}}{{Section
|sectionHeading=Blue-Green deployment
|anchor=blugredep
|alignment=Vertical
|structuredtext====Designer===

====Strategy====
Blue-Green deployment is a release management technique that reduces risk and minimizes downtime. It uses two production environments, known as Blue and Green or active and inactive, to provide reliable testing, continuous no-outage upgrades, and instant rollbacks. When a new release needs to be rolled out, an identical deployment of the application will be created using the Helm package and after testing is completed, the traffic is moved to the newly created deployment which becomes the active environment, and the old environment becomes inactive. This ensures that a fast rollback is possible by just changing route if a new issue is found with live traffic. The old inactive deployment is removed once the new active deployment becomes stable.

Service cutover is done by updating the Ingress rules. The diagram below shows the high-level approach to how traffic can be routed to Blue and Green deployments with Ingress rules.

[[File:DesBlueGreenDep.png|border]]

====Preparation====
Before you deploy Designer using the blue-green deployment strategy, complete the following preparatory steps:

#Create 3 hostnames as given below. The blue service hostname must contain the string ''blue''. For example, ''designer.blue.example.com'' or ''designer-blue.example.com''. The green service hostname must contain the string ''green''. For example, ''designer.green.example.com'' or ''designer-green.example.com''. The blue/green services can be accessed separately with the blue/green hostnames:
#*<code>designer.example.com</code> - For the production host URL, this is used for external access.
#*<code>designer.blue.example.com</code> - For the blue service testing.
#*<code>designer.green.example.com</code> - For the green service testing. 
#Configure the hostnames in the '''designer-values.yaml''' file under <code>ingress</code>. Annotations and paths can be modified as required. <source>ingress:
enabled: true
annotations: {}
paths: [/]
hosts:
- designer.example.com
- designer.blue.example.com
- designer.green.example.com</source> 

====Initial deployment====
The resources - ingress and persistent volume claims (PVC) - must be created initially before deploying the Designer service as these resources are shared between blue/green services and they are required to be created at the very beginning of the deployment. These resources are not required for subsequent upgrades. The required values are passed using the <code>-- set</code> flag in the following steps. Values can also be directly changed in the values.yaml file.

#Create Persistent Volume Claims required for the Designer service (assuming the volume service name is <code>designer-volume</code>). <code>helm upgrade --install designer-volume -f designer-values.yaml designer-9.0.xx.tgz --set designer.deployment.strategy=blue-green-volume</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>designer.deployment.strategy=blue-green-volume</code> - This denotes that the Helm install will create a persistent volume claim in the blue/green strategy.
#Create Ingress rules for the Designer service (assuming the ingress service name will be designer-ingress): <code>helm upgrade --install designer-ingress -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.deployment.strategy=blue-green-ingress --set designer.deployment.color=green</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>designer.deployment.strategy=blue-green-ingress</code> - This denotes that the Helm install will create ingress rules for the Designer service. <code>designer.deployment.color=green</code> - This denotes that the current production (active) color is green.
#Deploy the Designer service color selected in step 2. In this case, green is selected and assuming the service name is <code>designer-green</code>: <code>helm upgrade --install designer-green -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.deployment.strategy=blue-green --set designer.image.tag=9.0.1xx.xx.xx --set designer.deployment.color=green</code>

====Upgrade====

#Identify the current production color by checking the Designer ingress rules (<code>kubectl describe ingress designer-ingress</code>). Green is the production color in the below example as the production host name points to the green service. [[File:DesUpgStep1.png|border]]
#Deploy the Designer service on to the non-production color. In the above example, blue is the non-production color and assuming the service name will be designer-blue: <code>helm upgrade --install designer-blue -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.deployment.strategy=blue-green --set designer.image.tag=9.0.1xx.xx.xx --set designer.deployment.color=blue</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>designer.deployment.strategy=blue-green</code> - This denotes that the Designer service is installed using the blue-green strategy. <code>designer.image.tag=9.0.1xx.xx.xx</code> - This denotes the new Designer version to be installed, for example, <code>9.0.116.08.12</code>. <code>designer.deployment.color=blue</code> - This denotes that the blue color service is installed. The non-production color can be accessed with the non-production host name (for example, <code>designer.blue.example.com</code>). Testing can be done using this URL.

'''NodePort Service'''

The <code>designer-green</code> release creates a service called <code>designer-green</code> and the <code>designer-blue</code> release creates a service called <code>designer-blue</code>. If you are using NodePort services, ensure that the value of <code>designer.service.nodePort</code> is not the same for both the releases. In other words, you should assign dedicated node ports for the releases. The default value for <code>designer.service.nodePort</code> is '''30180'''. If this was applied to <code>designer-green</code>, use a different value for <code>designer-blue</code>, for example, '''30181'''. Use the below helm command to achieve this:

<code>helm upgrade --install designer-blue -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.deployment.strategy=blue-green --set designer.image.tag=9.0.1xx.xx.xx --set designer.deployment.color=blue --set designer.service.nodePort=30181</code>
====Cutover====
Once testing is completed on the non-production color, traffic can be moved to the new version by updating the Ingress rules:

#Update the Designer Ingress with the new deployment color by running the following command (in this case, blue is the new deployment color, that is, the non-production color): <code>helm upgrade --install designer-ingress -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.deployment.strategy=blue-green-ingress --set designer.deployment.color=blue</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>designer.deployment.strategy=blue-green-ingress</code> - This denotes that the helm install will create ingress rules for the Designer service. <code>designer.deployment.color=blue</code> - This denotes that the current production (active) color is blue.
#Verify the ingress rules by running the following command: <code>kubectl describe ingress designer-ingress</code> The production host name must point to the new color service.

====Rollback====
If the upgrade must be rolled back, the ingress rules can be modified to point to the old deployment pods (green, in this example) by performing a cutover again.

#Perform a cutover using the following command: <code>helm upgrade --install designer-ingress -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.deployment.strategy=blue-green-ingress --set designer.deployment.color=green</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>designer.deployment.strategy=blue-green-ingress</code> - This denotes that the Helm install will create Ingress rules for the Designer service. <code>designer.deployment.color=green</code> - This denotes that the the current production (active) color is green.
#Verify the Ingress rules by running the following command: <code>kubectl describe ingress designer-ingress</code> The production host name must point to the green service.

===DAS===

====Strategy====
As with Designer, the Blue-Green strategy can be adopted for DAS as well. The Blue-Green architecture used for DAS is given below. Here, the cutover mechanism is controlled by Service, the Kubernetes manifest responsible for exposing the pods. The Ingress, when enabled, will point to the appropriate service based on the URL.

[[File:DASBlueGreenDep.png|border]]

====Initial deployment====
The Ingress must be created initially before deploying the DAS service since it is shared between blue/green services and it is required to be created at the very beginning of the deployment. The Ingress is not required for subsequent upgrades. The required values are passed using the <code>-- set</code> flag in the following steps. Values can also be directly changed in the values.yaml file.

#Deploy initial DAS pods and other resources by choosing an active color, in this example, green. Use the below command to create a <code>designer-das-green</code> service: <code>helm upgrade --install designer-das-green -f designer-das-values.yaml designer-das-100.0.106+xxxx.tgz --set das.deployment.strategy=blue-green --set das.image.tag=9.0.1xx.xx.xx --set das.deployment.color=green</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>das.deployment.strategy=blue-green</code> - This denotes that the DAS service will be installed using the blue-green deployment strategy. <code>das.image.tag=9.0.1xx.xx.xx</code> - This denotes the DAS version to be installed, for example, <code>9.0.111.04.4</code>. <code>das.deployment.color=green</code> - This denotes that the green color service is installed.
#Once the initial deployment is done, the pods have to be exposed to the <nowiki><code>designer-das</code></nowiki> service. Execute the following command to create the <nowiki><code>designer-das</code></nowiki> service: <code>helm upgrade --install designer-das designer-das-100.0.106+xxx.tgz -f designer-das-values.yaml --set das.deployment.strategy=blue-green-service --set das.deployment.color=green</code> The values.yaml overrides passed as an argument to the above helm upgrade <code>das.deployment.strategy=blue-green-service</code> - This denotes that the designer-das service will be installed and exposed to the active color pods. <code>das.deployment.color=green</code> - This denotes that the designer-das service will point to green pods.

'''NodePort Service'''

The <code>designer-das-green</code> release creates a service called <code>designer-das-green</code> and the <code>designer-das-blue</code> release creates a service called <code>designer-das-blue</code>. If you are using NodePort services, ensure that the value of <code>designer.service.nodePort</code> is not the same for both the releases. In other words, you should assign dedicated node ports for the releases. The default value for <code>designer.service.nodePort</code> is '''30280'''. If this was applied to <code>designer-das-green</code>, use a different value for <code>designer-das-blue</code>, for example, '''30281'''. Use the below helm command to achieve this:
<code>helm upgrade --install designer-das designer-das-100.0.106+xxx.tgz -f designer-das-values.yaml --set das.deployment.strategy=blue-green-service --set das.deployment.color=green --set das.service.nodePort=30281</code>
====Canary====
Canary is optional and is only used along with Blue-Green. It is recommended in production. Canary pods are generally used to test new versions of images with live traffic. If you are not opting for Canary, skip the steps in this section.

'''Canary deployment'''

#Identify the current production color by checking the <code>designer-das</code> service selector labels (<code>kubectl describe service designer-das</code>). Green is the production color in the below example as the selector label is <code>color=green</code>. [[File:CanaryInDepStep1.png|border]]
#To deploy canary pods, the <code>das.deployment.strategy</code> value must be set to <code>canary</code> in the '''designer-das-values.yaml''' file or using the <code>-- set</code> flag as shown in the command below: <code>helm upgrade --install designer-das-canary -f das-values.yaml designer-das-100.0.106+xxxx.tgz --set das.deployment.strategy=canary --set das.image.tag=9.0.1xx.xx.xx --set das.deployment.color=green</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>das.deployment.strategy=canary</code> - This denotes that the Helm install will create canary pods. <code>das.deployment.color=green</code> - This denotes that the current production (active) color is green.{{NoteFormat|1=To make sure Canary pods receive live traffic, they have to be exposed to the <code>designer-das</code> service by setting <code>das.deployment.color=<active_color></code>, which is obtained from step 1.|2=}}
#Once canary pods are up and running, ensure that the designer-das service points to the canary pods using the <code>kubectl describe svc designer-das</code> command. [[File:CanaryEndpoints.png|border]] The IP address present in the Endpoints must match the IP address of the canary pod. The canary pod's IP address is obtained using the <code>kubectl describe pod <canary_pod_name></code> command. [[File:CanaryIPs.png|border]]

'''Cleaning up'''

After completing canary testing, the canary pods must be cleaned up.

The <code>das.deployment.replicaCount</code> must be made zero and the release is upgraded. It can be changed in the '''designer-das-values.yaml''' file or through the <code>--set</code> flag as follows:

*<code>helm upgrade --install designer-das-canary -f das-values.yaml designer-das-100.0.106+xxxx.tgz --set das.deployment.strategy=canary --set das.image.tag=9.0.1xx.xx.xx --set das.deployment.color=blue --set das.deployment.replicaCount=0</code>
{{AnchorDiv|dasupgrade}}
====Upgrade====

#Identify the current production color by checking the <code>designer-das</code> service selector labels (<code>kubectl describe service designer-das</code>). Green is the production color in the below example as the selector label is <code>color=green</code>. [[File:DasBGUpgStep1.png|border]]
#Deploy the DAS service on to the non-production color. For the above example, blue is the non-production color and assuming the service name is <code>designer-das-blue</code>): <code>helm upgrade --install designer-das-blue -f das-values.yaml designer-das-100.0.106+xxxx.tgz --set das.deployment.strategy=blue-green --set das.image.tag=9.0.1xx.xx.xx --set das.deployment.color=blue</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>das.deployment.strategy=blue-green</code> - This denotes that the DAS service is installed using the blue-green strategy. <code>das.image.tag=9.0.1xx.xx.xx</code> - This denotes the new DAS version to be installed, for example, <code>9.0.111.05.5</code>. <code>das.deployment.color=blue</code> - This denotes that the blue color service is installed. The non-production color can be accessed with the non-production service name.
{{AnchorDiv|dascutover}}
====Cutover====
Once testing is completed on the non-production color, traffic can be moved to the new version by updating the <code>designer-das</code> service.

#Update the <code>designer-das</code> service with the new deployment color by executing the below command. In this example, blue is the new deployment color (non-production color). <code>helm upgrade --install designer-das-service -f designer-das-values.yaml designer-das-100.0.106+xxxx.tgz --set das.deployment.strategy=blue-green-service --set das.deployment.color=blue</code>
#Verify the service by executing the <code>kubectl describe service designer-das</code> command. The type label must have the active color's label, that is, <code>color=blue</code>.

====Rollback====

#If the upgrade must be rolled back, cutover has to performed again to make the service point to the old deployment (green) again. Use the below command to perform the cutover: <code>helm upgrade --install designer-das-service -f designer-das-values.yaml designer-das-100.0.106+xxxx.tgz --set das.deployment.strategy=blue-green-service --set das.deployment.color=green</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>das.deployment.strategy=blue-green-service</code> - This denotes that the Helm install will create ingress rules for the DAS service. <code>das.deployment.color=green</code> - This denotes that the current production (active) color is green.
#Verify the service by executing the <code>kubectl describe service designer-das</code> the command. The type label must have the active color's label, that is, <code>color=green</code>.
|Status=No
}}{{Section
|sectionHeading=Validations and checks
|anchor=valchk
|alignment=Vertical
|structuredtext=Here are some common validations and checks that can be performed to know if the deployment was successful.

*Check if the application pods are in running state by using the <code>kubectl get pods</code> command.

*Try to connect to the Designer or DAS URL as per the ingress rules from your browser. You must be able to access the Designer and DAS webpages.

 
|Status=No
}}{{Section
|sectionHeading=Post deployment procedures
|anchor=postdeppros
|alignment=Vertical
|structuredtext====Upgrading the Designer workspace===
Workspace resources must be upgraded after cutover. This will upgrade the system resources in the Designer workspace:

#Login to one of the Designer pods using the <code>kubectl exec -it <pod_name ></code> bash command.
#Execute the following migration command (this will create new directories/new files introduced in the new version): <code>node ./bin/cli.js workspace-upgrade -m -t <contact_center_id></code>
#Execute the workspace resource upgrade command (this will upgrade system resources, such as system service PHP files, internal audio files and callback resources): <code>node ./bin/cli.js workspace-upgrade -t <contact_center_id></code> In the above command, <code>contact_center_id</code> , is the Contact Center ID created in GWS for this tenant (workspace resources are located under the Contact Center ID folder (''/workspaces/<ccid>/workspace'')).
{{NoteFormat|The above steps will also be used for further upgrades.|}}

{{AnchorDiv|updateflowset}}
===Updating the flowsettings file===
Post deployment, the '''flowsettings.json''' file can be modified through a Helm install as follows:

#Extract the Designer Helm Chart and find the '''flowsettings.yaml''' file under the ''Designer Chart > Config'' folder.
#Modify the necessary settings (refer to the ''Post deployment configuration settings reference table'' for the different settings and their allowed values).
#Execute the below Helm upgrade command on the non-production color service. It can be done as part of the Designer upgrade by passing the '''flowsettings.yaml''' file using the <code>--values</code> flag. In this case, a new Designer version can be used for the upgrade. If it is only a '''flowsettings.json''' update, the same Designer version is used. <code>helm upgrade --install designer-blue -f designer-values.yaml -f flowsettings.yaml designer-9.0.xx.tgz --set designer.deployment.strategy=blue-green --set designer.image.tag=9.0.1xx.xx.xx --set designer.deployment.color=blue</code>
#Once testing is completed on the non-production service, perform the cutover step as mentioned in the Cutover section (Designer Blue-Green deployment). After cutover, the production service will contain the updated settings. The non-active color Designer must also be updated with the updated settings after the cutover. 
|Status=No
}}
|PEPageType=45d1441f-dc69-4a17-bd47-af5d811ce167
}}

DES/Current/DESPEGuide/Provision

2022-03-25T12:31:48Z

MPandian: Published

{{Article
|Standalone=No
|DisplayName=Platform / Configuration Server and GWS settings for Designer
|TocName=Platform / Configuration Server and GWS settings for Designer
|Context=Learn about the Configuration Server objects and settings required for Designer.
|ComingSoon=No
|Role=Administrator
|Section={{Section
|sectionHeading=Create roles for Designer
|anchor=desroles
|alignment=Vertical
|structuredtext=Designer uses roles and access groups to determine permissions associated with the logged-in user. To enable this, you must make these changes in GAX or CME.

Designer supports a number of bundled roles suitable for various levels of users.

*'''Designer Developer''' - Most users fall into this category. These users can create Designer applications, upload audio, and create business controls. They have full access to Designer Analytics.

*'''Designer Business User''' - These users cannot create objects but they can manage them (for example, upload audio, change data tables, and view analytics).

*'''Designer Analytics''' - These users only have access to Designer Analytics.

*'''Designer Admin''' - These users can set up and manage partitions associated with users and Designer objects.
*'''Designer Operations''' - Users with this role have full access to all aspects of the Designer workspace. This includes the '''Operations''' menu (normally hidden), where they can perform advanced operational and maintenance tasks.

To create these roles, import the '''.conf''' files included in the '''Designer Deployment''' package. They are located in the '''packages/roles/''' folder.

In addition, ensure the following for user accounts that need access to Designer:

*The user must have read permissions on its own Person object.
*Users must be associated with one or more roles via access groups.
*The on-Premises user must have at least read access on the user, access group(s), and roles(s).
*The access groups must have read/write permissions to the Agent Setup folders - Scripts and Transactions.
|Status=No
}}{{Section
|sectionHeading=Update the DesignerEnv transaction list
|anchor=desenv
|alignment=Vertical
|structuredtext=Designer requires a transaction list for configuration purposes as described in other sections of this document. The '''DesignerEnv''' transaction list is automatically created in on logging onto Designer.

#Edit any values according to the descriptions provided in the {{Link-SomewhereInThisVersion|manual=DESPEGuide|topic=Configure|anchor=postdepconf|display text=Post deployment configuration settings reference table}}.
#Save the list.
#Ensure Designer users have at least read access to the '''DesignerEnv''' transaction list.
|Status=No
}}{{Section
|sectionHeading=Platform settings
|anchor=platset
|alignment=Vertical
|structuredtext=The platform settings listed below must be configured if the Designer application is used for voice calls.
{{{!}} class="wikitable"
{{!}}Component
{{!}}Config Key
{{!}}Value
{{!}}Description
{{!}}-
{{!}}SIP Switch -> Voip Services -> msml service
{{!}}userdata-map-format
{{!}}sip-headers-encoded
{{!}}Option needs to set to pass JSON data as user data in SIPS.
{{!}}-
{{!}}SIP Switch -> Voip Services -> msml service
{{!}}userdata-map-filter
{{!}}*
{{!}}To allow userdata passing to MSML service.
{{!}}-
{{!}} rowspan="7"{{!}}SIPServer --> TServer
{{!}}divert-on-ringing
{{!}}false
{{!}}RONA is handled by the platform.
{{!}}-
{{!}}agent-no-answer-timeout
{{!}}12
{{!}}
{{!}}-
{{!}}agent-no-answer-action
{{!}}notready
{{!}}
{{!}}-
{{!}}agent-no-answeroverflow
{{!}}""
{{!}}No value, empty.
{{!}}-
{{!}}after-routing-timeout
{{!}}24
{{!}}
{{!}}-
{{!}}sip-treatments-continuous
{{!}}true
{{!}}
{{!}}-
{{!}}msml-record-support
{{!}}true
{{!}}To allow routed calls recording via the Media Server.
{{!}}-
{{!}}Switch object annex --> gts
{{!}}ring-divert
{{!}}1
{{!}}
{{!}}-
{{!}}ORS --> orchestration
{{!}}new-session-on-reroute
{{!}}false
{{!}}Required for SIPS Default Routing ([https://intranet.genesys.com/pages/viewpage.action?pageId=55813481 Default Routing handling (Voice)]).
{{!}}-
{{!}}MCP
{{!}}[vxmli] transfer.allowed
{{!}}TRUE
{{!}}Required for Transfer block (allows VXML Transfer in MCP).
{{!}}-
{{!}}MCP
{{!}}[cpa] outbound.method
{{!}}NATIVE
{{!}}Required for Transfer block (allow CPA detection for Transfer ).
{{!}}-
{{!}}UCS
{{!}}[cview] enabled
{{!}}TRUE
{{!}}Enables Customer Context Services.
{{!}}}
|Status=No
}}{{Section
|sectionHeading=GWS configuration
|anchor=gwsconfig
|alignment=Vertical
|structuredtext=Ensure that the following steps are performed in GWS.
====Create Contact Center====
Create a contact center in GWS if it is not already created. Refer to the [https://docs.genesys.com/Documentation/HTCC/8.5.2/API/Welcome GWS documentation] for more information on this.
====Create GWS Client====
Create new GWS client credentials if they are not already created . Refer to the [https://docs.genesys.com/Documentation/HTCC/8.5.2/API/Welcome GWS documentation] for more information on this.
|Status=No
}}
|PEPageType=55cef4ff-9306-4313-8fd8-377282a38478
}}

DES/Current/Deployment

2022-03-24T19:41:49Z

MPandian: Published

{{MintyDocsManual
|product=Draft:DES
|version=Current
|manual=Deployment
|alternateforms=Form:ArticleUnstructured,Form:FAQ,Form:TaskSummary
|displayname=Designer Deployment Guide
|pagination=no
|topicslist=* -Deployment Details
** DeployDesigner9012214
** DeployDesigner
** Deploy
|defaultform=Form:Article
|inherit=no
}}
{{Article
|PageType=Manual
}}

DES/Current/Deployment/DeployDesigner9012214

2022-03-24T19:37:29Z

MPandian: Published

{{Article
|Standalone=No
|DisplayName=Deploy Designer (versions v9012214 and above)
|TocName=Deploy Designer (versions v9012214 and above)
|Context=Learn how to deploy Designer as a service in a Kubernetes cluster (for '''DesDepMnfst v9012214''' and above).
|ComingSoon=No
|Platform=GenesysEngage-onpremises
|Section={{Section
|sectionHeading=1. About this document
|anchor=abtdoc
|alignment=Vertical
|structuredtext=This document guides you through the process of deploying and configuring Designer and Designer Application Server (DAS) as a service in a Kubernetes (K8s) cluster.

Information on the following topics is provided:

*Overview of Designer and DAS
*Configuration details
*Deployment process
*Enabling optional features
*Cleanup
*Known limitations

===1.1 Intended audience===
This document is intended for use primarily by system engineers and other members of an implementation team who will be involved in configuring and installing Designer and DAS, and system administrators who will maintain Designer and DAS installations.

To successfully deploy and implement applications in Designer and DAS, you must have a basic understanding of and familiarity with:

*Network design and operation
*Network configurations in your organization
*Kubernetes
*Genesys Framework architecture and functions

===1.2 Before you begin===

#Install Kubernetes. Refer to the [https://kubernetes.io/docs/home/ Kubernetes documentation site] for installation instructions. You can also refer to the [https://docs.genesys.com/Documentation/System/8.5.x/DDG/Welcome Genesys Docker Deployment Guide] for information on Kubernetes and High Availability.
#Install Helm according to the instructions outlined in the [https://helm.sh/docs/using_helm/ Helm documentation site].

After you complete the above mandatory procedures, return to this document to complete an on-premise deployment of Designer and DAS as a service in a K8s cluster.
 
|Status=No
}}{{Section
|sectionHeading=2. Product overview
|anchor=prodoverview
|alignment=Vertical
|structuredtext=The following sections provide a brief overview of Designer and DAS.

===2.1 Designer===
The Designer service provides a web UI to build and manage VXML and SCXML based self-service and assisted service applications for a number of media types. It stores data on the local file system and is synchronized across instances by using services like Network File System (NFS). Genesys customers can build applications using a simple drag and drop method, and assign contact points (Route Points and other media endpoints) to applications directly from the Designer UI. Insights into runtime behavior of applications and troubleshooting aid is provided by Designer Analytics, which includes a rich set of dashboards based on session detail records (SDR) from data stored in Elasticsearch.

Designer offers the following features:

*Applications for working with phone, chat, email, SMS (text messages), Facebook, Twitter, and open media types.
*Bots, ASR, TTS capabilities for self-service.
*Assisted service or routing.
*Callback.
*Business Controls.
*Audio, message management.
*Grammars management.
*Contact points management - route points, chat end points, email pop-client/mailboxes.
*Analytics dashboards through embedded Kibana.

Designer is an Express/Node.js application. The UI is designed using Angular powered Bootstrap. Application data (SCXML and VXML) is stored as a file system. Designer Analytics and Audit data is stored in Elasticsearch.

===2.2 Designer Application Server (DAS)===
Designer Application Server (DAS) hosts and serves the Designer generated application files (SCXML and VXML), audio, and grammars. It also provides:

*Runtime evaluation of Business Controls (business hours, special days, emergency flags and data tables).
*Callback interface to GES.

DAS uses built-in NGINX to front requests. It consists of 3 modules: NGINX, PHP, and Node.js.

*Requests for static workspace content (SCXML, VXML, JS, audio, grammar, etc) are handled by the NGINX module.
*Requests for PHP content are processed by the FastCGI PHP module.
*SDR (Analytics) processing requests are handled by the DAS Node.js module.

{{NoteFormat|Files generated by Designer can be served only by DAS. Designer will work only with DAS.|}}

===2.3 Deployment architecture===
The below architecture diagram illustrates a sample premise deployment of Designer and DAS:

[[File:Premise-Designer-DAS-architecture.png]]

===2.4 High Availability (HA), Disaster Recovery (DR), and Scalability===
Designer and DAS must be deployed as highly available in order to avoid single points of failure. A minimum of 2 replicas of each service must be deployed to achieve HA.

The Designer and DAS service pods can be automatically scaled up or down based on metrics such as CPU and memory utilization. The ''Deployment configuration settings'' section explains how to configure HA and auto-scaling.

Refer to the [https://docs.genesys.com/Documentation/System/8.5.x/DDG/HAandDRNotes Genesys Docker Deployment Guide] for more information on general HA recommendation for Kubernetes.
 
|Status=No
}}{{Section
|sectionHeading=3. Prerequisites
|anchor=prereqs
|alignment=Vertical
|structuredtext=Before deploying Designer, ensure the following resources are deployed, configured, and accessible:

===3.1 Mandatory prerequisites===

*Kubernetes 1.12+
*Helm 3.0
*Docker
**To store Designer and DAS docker images to the local docker registry.
*Ingress Controller
**If Designer and DAS are accessed from outside of a K8s cluster, it is recommended to deploy/configure an ingress controller (for example, NGINX), if not already available. Also, the Blue-Green deployment strategy works based on the ingress rules.
**The Designer UI requires ''Session Stickiness''. Configure session stickiness in the ''annotations'' parameter in the '''values.yaml''' file during Designer installation.
*Persistent Volumes (PVs)
**Create persistent volumes for workspace storage (5 GB minimum) and logs (5 GB minimum)
**Set the access mode for these volumes to ''ReadWriteMany''.
**The Designer manifest package includes a sample YAML file to create Persistent Volumes required for Designer and DAS.
**Persistent volumes must be shared across multiple K8s nodes. Genesys recommends using NFS to create Persistent Volumes.
*Shared file System - NFS
**For production, deploy the NFS server as highly available (HA) to avoid single points of failure. It is also recommended that the NFS storage be deployed as a Disaster Recovery (DR) topology to achieve continuous availability if one region fails.
**By Default, Designer and DAS containers run as a Genesys user (<code>uid:gid 500:500</code>). For this reason, the shared volume must have permissions that will allow write access to <code>uid:gid 500:500</code>. The optimal method is to change the NFS server host path to the Genesys user: <code>chown -R genesys:genesys</code>.
**The Designer manifest package includes a sample YAML file to create an NFS server. Use this only for a demo/lab setup purpose.
**Azure Files Storage - If you opt for Cloud storage, then Azure Files Storage is an option to consider and has the following requirements: A Zone-Redundant Storage for RWX volumes replicated data in zone redundant (check this), shared across multiple pods.
***Provisioned capacity : 1 TiB
***Baseline IO/s : 1424
***Burst IO/s : 4000
***Egress Rate : 121.4 MiBytes/s
***Ingress Rate : 81.0 MiBytes/s
*Genesys Web Services (GWS) 9.x
**Configure GWS to work with a compatible version of Configuration Server.
*Other Genesys Components
**ORS ORS 8.1.400.x
**Nexus 9.x
**URS 8.1.400.x

===3.2 Optional prerequisites===

*Elasticsearch 7.8.0
**Elasticsearch is used for Designer Analytics and audit trail.
*Redis 3.2.x
**Redis is used for resource index caching and multi-user collaboration locks on Designer resources.
|Status=No
}}{{Section
|sectionHeading=4. Deployment configuration settings (Helm values)
|anchor=depconfigset
|alignment=Vertical
|structuredtext=This section provides information on the various settings that have to be configured in Designer and DAS. The configuration settings listed below will be used during the deployment of Designer and DAS. That is, these settings will be used during initial deployment / upgrade. These settings can be configured in the '''values.yaml''' Helm file.
===4.1 Designer deployment settings===
The following table provides information on the Designer deployment settings. These settings are configured in the '''designer-values.yaml''' file.
{{{!}} class="wikitable"
{{!}}Parameter
{{!}}Description
{{!}}Mandatory?
{{!}}Default Value
{{!}}-
{{!}}<code>designer.deployment.replicaCount</code>
{{!}}Number of service instances to be created.
{{!}}Mandatory
{{!}}<code>2</code>
{{!}}-
{{!}}<code>designer.deployment.maxreplicaCount</code>
{{!}}The maximum number of replicas to be created. It is recommended to configure this setting if auto-scaling is used.
{{!}}Optional
{{!}}<code>10</code>
{{!}}-
{{!}}<code>designer.deployment.strategy</code>
{{!}}The deployment strategy to follow. This determines which type of resources are deployed. Valid values are: <code>rollingupdate, blue-green, blue-green-volume, blue-green-ingress, grafana</code>.

*'''rollingupdate''' - default Kubernetes update strategy where resources will be updated using the rolling upgrade strategy.
*'''blue-green''' - for deploying and upgrading the Designer service using the blue-green strategy.
*'''blue-green-volume''' - for the blue/green upgrade, this is to create a Persistent Volume Claim (PVC) for the very first time.
*'''blue-green-ingress''' - for the blue/green upgrade, this is to create an ingress for the first time and update the ingress during a service cutover.
*'''grafana''' - for deploying the Grafana dashboard.
{{!}}Mandatory
{{!}}<code>rollingupdate</code>
{{!}}-
{{!}}<code>designer.deployment.color</code>
{{!}}This is to deploy/upgrade the Designer service in a blue-green upgrade strategy. Valid values are: <code>blue, green</code>.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>designer.deployment.type</code>
{{!}}This is to specify the type of deployment. Valid value: <code>Deployment</code>.
{{!}}Optional
{{!}}<code>Deployment</code>
{{!}}-
{{!}}<code>designer.image.registry</code>
{{!}}The registry that the organization uses for storing images.
{{!}}Mandatory
{{!}}
{{!}}-
{{!}}<code>designer.image.repository</code>
{{!}}Docker repository that contains the images for Designer.
{{!}}Mandatory
{{!}}
{{!}}-
{{!}}<code>designer.image.tag</code>
{{!}}Designer image version.
{{!}}Mandatory
{{!}}9.0.110.07.7
{{!}}-
{{!}}<code>designer.image.PullPolicy</code>
{{!}}Designer image pull policy (imagePullPolicy). Valid values: <code>Always, IfNotPresent, Never</code>.

*'''Always''' - always pull the image.
*'''IfNotPresent''' - pull the image only if it does not already exist on the node.
*'''Never''' - never pull the image.
{{!}}Mandatory
{{!}}<code>IfNotPresent</code>
{{!}}-
{{!}}<code>designer.image.imagePullSecrets</code>
{{!}}Secret name containing credentials for authenticating access to the Docker repository.
{{!}}Mandatory
{{!}}
{{!}}-
{{!}}<code>designer.volumes.workspacePvc.create</code>
{{!}}If a persistent volume is to be created, this value has to be <code>true</code>.
{{!}}Mandatory
{{!}}<code>true</code>
{{!}}-
{{!}}<code>designer.volumes.workspacePvc.mountPath</code>
{{!}}The path where the workspace volume is to be mounted inside the Designer container.
{{!}}Mandatory
{{!}}<code>/designer/workspace</code>
(Changing this value is not recommended.)
{{!}}-
{{!}}<code>designer.volumes.workspacePvc.claim</code>
{{!}}Persistent volume claim name for the workspace.
{{!}}Mandatory
{{!}}<code>designer-managed-disk</code>
{{!}}-
{{!}}<code>designer.volumes.workspacePvc.claimSize</code>
{{!}}Size of the persistent volume claim for the workspace.
The persistent volume must be equal to or greater than this size.
{{!}}Mandatory
{{!}}
{{!}}-
{{!}}<code>designer.volumes.workspacePvc.storageClass</code>
{{!}}storageClassName provided in the persistent volume that is created for the Designer workspace (example, '''nfs''').
{{!}}Mandatory
{{!}}
{{!}}-
{{!}}<code>designer.volumes.logsPvc.create</code>
{{!}}If a PVC volume is to be created, this value has to be <code>true</code>, else <code>false</code>.
{{!}}Mandatory
{{!}}<code>true</code>
{{!}}-
{{!}}<code>designer.volumes.logsPvc.mountPath</code>
{{!}}The path where the Designer logs volume is to be mounted inside the Designer container.
{{!}}Mandatory
{{!}}<code>/designer/logs</code>
{{!}}-
{{!}}<code>designer.volumes.logsPvc.claim</code>
{{!}}Persistent volume claim name for logs.
{{!}}Mandatory
{{!}}<code>designer-logs</code>
{{!}}-
{{!}}<code>designer.volumes.logsPvc.claimSize</code>
{{!}}Size of the persistent volume claim for the Designer logs.
The persistent volume must be equal to or greater than this size.
{{!}}Mandatory
{{!}}
{{!}}-
{{!}}<code>designer.volumes.logsPvc.storageClass</code>
{{!}}storageClassName provided in the persistent volume that is created for the Designer logs (example, '''nfs''').
{{!}}Mandatory
{{!}}
{{!}}-
{{!}}<code>designer.podVolumes</code>
{{!}}Log and workspace persistent volume claim names and name of the volumes attached to the pod.
{{!}}Mandatory
{{!}}
<source>designer:
podVolumes:
- name: designer-pv-volume
persistentVolumeClaim:
claimName: designer-managed-disk
- name: designer-log-volume
persistentVolumeClaim:
claimName: designer-logs</source>
{{!}}-
{{!}}<code>designer.volumeMounts</code>
{{!}}Name and mount path of the volumes to be attached to the Designer pods.
{{!}}Mandatory
{{!}}
<source>volumeMounts:
- name: designer-pv-volume
mountPath: /designer/workspace
- name: designer-log-volume
mountPath: /designer/logs</source>
{{!}}-
{{!}}<code>designer.livenessProbe.path</code>
{{!}}Designer liveness probe API path.
{{!}}Mandatory
{{!}}<code>/health</code>
{{!}}-
{{!}}<code>designer.livenessProbe.containerPort</code>
{{!}}Port running the container.
{{!}}Mandatory
{{!}}<code>8888</code>
{{!}}-
{{!}}<code>designer.livenessProbe.startupDelay</code>
{{!}}The liveness probe will be started after a given delay as specified here.
{{!}}Mandatory
{{!}}<code>20</code>
{{!}}-
{{!}}<code>designer.livenessProbe.checkInterval</code>
{{!}}The interval between each liveness probe request.
{{!}}Mandatory
{{!}}<code>5</code>
{{!}}-
{{!}}-
{{!}}<code>designer.livenessProbe.failureCount</code>
{{!}}Number of liveness probe failures after which, to mark the container as unstable or restart.
{{!}}Mandatory
{{!}}<code>5</code>
{{!}}-
{{!}}<code>designer.readinessProbe.path</code>
{{!}}Designer readiness probe API path.
{{!}}Mandatory
{{!}}<code>/health</code>
{{!}}-
{{!}}<code>designer.readinessProbe.containerPort</code>
{{!}}Port running the container.
{{!}}Mandatory
{{!}}<code>8888</code>
{{!}}-
{{!}}<code>designer.readinessProbe.startupDelay</code>
{{!}}The readiness probe will be started after a given delay as specified here.
{{!}}Mandatory
{{!}}<code>20</code>
{{!}}-
{{!}}<code>designer.readinessProbe.checkInterval</code>
{{!}}The interval between each readiness probe request.
{{!}}Mandatory
{{!}}<code>5</code>
{{!}}-
{{!}}<code>designer.readinessProbe.failureCount</code>
{{!}}Number of readiness probe failures after which, to mark the container as unstable or restart.
{{!}}Mandatory
{{!}}<code>5</code>
{{!}}-
{{!}}<code>designer.designerSecrets.enabled</code>
{{!}}This enables providing the GWS Client ID and Secret as an input to the Designer pods. Kubernetes Secrets is used to store the GWS client credentials.
{{!}}Mandatory
{{!}}<code>true</code>
{{!}}-
{{!}}<code>designer.designerSecrets.secrets</code>
{{!}}GWS Client ID and GWS Client Secret. Create a new GWS Client if it does not exist. A link to information on creating a new GWS Client is provided in the ''Platform settings'' section.
{{!}}Mandatory
{{!}}
{{!}}-
{{!}}<code>designer.service.enabled</code>
{{!}}Set to <code>true</code> if the service must be created.
{{!}}Optional
{{!}}<code>true</code>
{{!}}-
{{!}}<code>designer.service.type</code>
{{!}}Service type. Valid values are: <Code>ClusterIP, NodePort, LoadBalancer</Code>.
{{!}}Mandatory
{{!}}<code>NodePort</code>
{{!}}-
{{!}}<code>designer.service.port</code>
{{!}}The Designer service port to be exposed in the cluster.
{{!}}Mandatory
{{!}}<code>8888</code>
{{!}}-
{{!}}<code>designer.service.targetPort</code>
{{!}}The Designer application port running inside the container.
{{!}}Mandatory
{{!}}<code>http</code>
{{!}}-
{{!}}<code>designer.service.nodePort</code>
{{!}}Port to be exposed in case service type is <code>NodePort</code>.
{{!}}Mandatory for <code>designer.service.type=NodePort</code>.
{{!}}<code>30180</code>
{{!}}-
{{!}}<code>designer.service.termination_grace_period</code>
{{!}}The period after which Kubernetes starts to delete the pods after service termination.
{{!}}Optional
{{!}}<code>30</code> seconds.
{{!}}-
{{!}}<code>designer.ingress.enabled</code>
{{!}}Set to <code>true</code> to enable ingress.
Ingress should be enabled for all cases except for a lab/demo setup.
{{!}}Mandatory
{{!}}<code>true</code>
{{!}}-
{{!}}<code>designer.ingress.annotations</code>
{{!}}Annotations added for ingress. The Designer UI requires Session Stickiness if the replica count is more than 1. Configure Session Stickiness based on the ingress controller type. Configuration specific to ingress such as Session Stickiness can be provided here.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>designer.ingress.paths</code>
{{!}}Ingress path
{{!}}Mandatory
{{!}}<code>[/]</code>
{{!}}-
{{!}}<code>designer.ingress.hosts</code>
{{!}}Hostnames to be configured in ingress for the Designer service.
{{!}}Mandatory
{{!}} - <app1>.example.com 
- <app1>.blue.example.com 
- <app1>.green.example.com
{{!}}-
{{!}}<code>designer.ingress.tls</code>
{{!}}TLS configuration for ingress.
{{!}}Optional
{{!}}<code>[]</code>
{{!}}-
{{!}}<code>designer.resources.limits.cpu</code>
{{!}}Maximum amount of CPU that K8s allocates for the container.
{{!}}Mandatory
{{!}}<code>600m</code>
{{!}}-
{{!}}<code>designer.resources.limits.memory</code>
{{!}}Maximum amount of memory that K8s allocates for the container.
{{!}}Mandatory
{{!}}<code>1Gi</code>
{{!}}-
{{!}}<code>designer.resources.requests.cpu</code>
{{!}}Guaranteed CPU allocation for the container.
{{!}}Mandatory
{{!}}<code>500m</code>
{{!}}-
{{!}}<code>designer.resources.requests.memory</code>
{{!}}Guaranteed memory allocation for the container.
{{!}}Mandatory
{{!}}<code>512Mi</code>
{{!}}-
{{!}}<code>designer.securityContext.runAsUser</code>
{{!}}This setting controls which user ID the containers are run with. This can be configured to run Designer as a non-root user. You can either use the '''Genesys''' user or arbitrary UIDs. Both are supported by the Designer base image. <code>500</code> is the ID of the Genesys user. 
The file system must reside within the Genesys user account in order to run Designer as a Genesys user. Change the NFS server host path to the Genesys user:
<code>chown -R genesys:genesys</code>.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>designer.securityContext.runAsGroup</code>
{{!}}Controls which primary group ID the containers are run with. This can be configured to run Designer as a non-root user. You can either use the '''Genesys''' userGroup (GID - <code>500</code>) or arbitrary GIDs. Both are supported by the Designer base image.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>designer.nodeSelector</code>
{{!}}To allow pods to be scheduled based on the labels assigned to the nodes.
{{!}}Optional
{{!}}Default value: 
<code>nodeSelector: {}</code> 
Sample value: 
<source>nodeSelector:
<label_key>: <label_value></source>
{{!}}-
{{!}}<code>designer.affinity</code>
{{!}}The K8s standard node affinity and anti-affinity configurations can be added here. Refer to the [https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/ this] topic in the Kubernetes documentation site for sample values.
{{!}}Optional
{{!}}<code>{}</code>
{{!}}-
{{!}}<code>designer.tolerations</code>
{{!}}Tolerations work with taints to ensure that pods are not scheduled on to inappropriate nodes. Refer to the [https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ Taints and Tolerations] topic in the Kubernetes documentation site for sample values.
{{!}}Optional
{{!}}<code>[]</code>
{{!}}-
{{!}}<code>designer.podDisruptionBudget.enabled</code>
{{!}}Set to <code>true</code> if a pod disruption budget is to be created.
{{!}}Optional
{{!}}<code>false</code>
{{!}}-
{{!}}<code>designer.podDisruptionBudget.minAvailable</code>
{{!}}The number of pods that should always be available during a disruption.
{{!}}Optional
{{!}}<code>1</code>
{{!}}-
{{!}}<code>designer.dnsPolicy</code>
{{!}}The DNS policy that should be applied to the Designer pods.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>designer.dnsConfig</code>
{{!}}The DNS configuration that should be applied to the Designer pods.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>designer.priorityClassName</code>
{{!}}The priority class name that the pods should belong to.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>designer.hpa.enabled</code>
{{!}}Enables K8s Horizontal Pod Autoscaler (HPA). It automatically scales the number of pods based on average CPU utilization and average memory utilization. For more information on HPA refer to [https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/ this] topic in the Kubernetes documentation site.
{{!}}Optional
{{!}}<code>false</code>
{{!}}-
{{!}}<code>designer.hpa.targetCPUPercent</code>
{{!}}The K8s HPA controller will scale up or scale down pods based on the target CPU utilization percentage specified here. It scales up or scales down pods between the range - <code>designer.deployment.replicaCount</code> and <code>designer.deployment.maxreplicaCount</code>.
{{!}}Optional
{{!}}<code>70</code>
{{!}}-
{{!}}<code>designer.hpa.targetMemoryPercent</code>
{{!}}The K8s HPA controller will scale up or scale down pods based on the target memory utilization percentage specified here. It scales up or scales down pods between the range - <code>designer.deployment.replicaCount</code> and <code>designer.deployment.maxreplicaCount</code>.
{{!}}Optional
{{!}}<code>70</code>
{{!}}-
{{!}}<code>designer.labels</code>
{{!}}Labels that will be added to the Designer pods.
{{!}}Optional
{{!}}<code>{}</code>
{{!}}-
{{!}}<code>designer.annotations</code>
{{!}}Annotations added to the Designer pods.
{{!}}Optional
{{!}}<code>{}</code>
{{!}}-
{{!}}<code>designer.prometheus.enabled</code>
{{!}}Set to <code>true</code> if Prometheus metrics must be enabled.
{{!}}Optional
{{!}}<code>false</code>
{{!}}-
{{!}}<code>designer.prometheus.tagName</code>
{{!}}Label key assigned to the pods/service to filter out.
{{!}}Optional
{{!}}<code>service</code>
{{!}}-
{{!}}<code>designer.prometheus.tagValue</code>
{{!}}Label value assigned to the pods/service to filter out.
{{!}}Optional
{{!}}<code>designer</code>
{{!}}-
{{!}}<code>designer.prometheus.instance</code>
{{!}}
{{!}}Optional
{{!}}<code>❴❴instance❵❵</code>
{{!}}-
{{!}}<code>designer.prometheus.serviceMonitor.enabled</code>
{{!}}Set to <code>true<Set/code> if a service monitor resource is needed to monitor the pods through the Kubernetes service.
{{!}}Optional
{{!}}<code>false</code>
{{!}}-
{{!}}<code>designer.prometheus.serviceMonitor.path</code>
{{!}}The path in which the metrics are exposed.
{{!}}Optional
{{!}}<code>/metrics</code>
{{!}}-
{{!}}<code>designer.prometheus.serviceMonitor.interval</code>
{{!}}The scrape interval specified for the Prometheus server. That is, the time interval at which the Prometheus server will fetch metrics from the service.
{{!}}Optional
{{!}}<code>10s</code>
{{!}}-
{{!}}<code>designer.prometheus.serviceMonitor.labels</code>
{{!}}Labels to be specified for the service monitor resource.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>designer.prometheus.alerts.enabled</code>
{{!}}Set to <code>true<Set/code> if Prometheus alerts must to be created.
{{!}}Optional
{{!}}<code>false</code>
{{!}}-
{{!}}<code>designer.prometheus.alerts.customalerts</code>
{{!}}Any custom alerts that are created must be specified here.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>designer.prometheus.alerts.labels</code>
{{!}}Labels to be specified for the alerts resource.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>designer.prometheus.alerts.<alert_names></code>
{{!}}Scenarios for which alerts need to be created.
{{!}}Optional
{{!}}'''designer.prometheus.alerts'''
<source>containerRestartAlert:
interval: 3m
threshold: 5
AlertPriority: CRITICAL
MemoryUtilization:
interval: 1m
threshold: 70
AlertPriority: CRITICAL
endpointAvailable:
interval: 1m
AlertPriority: CRITICAL
CPUUtilization:
interval: 1m
threshold: 70
AlertPriority: CRITICAL
containerReadyAlert:
interval: 1m
readycount: 1
AlertPriority: CRITICAL
WorkspaceUtilization:
interval: 3m
threshold: 80
workspaceClaim: designer-managed-disk
AlertPriority: CRITICAL
AbsentAlert:
interval: 1m
AlertPriority: CRITICAL
Health:
interval: 3m
AlertPriority: CRITICAL
WorkspaceHealth:
interval: 3m
AlertPriority: CRITICAL
ESHealth:
interval: 3m
AlertPriority: CRITICAL
GWSHealth:
interval: 3m
AlertPriority: CRITICAL</source>
{{!}}-
{{!}}<code>designer.grafana.enabled</code>
{{!}}Set to <code>true</code> if the Grafana dashboard is to be created.
{{!}}Optional
{{!}}<code>true</code>
{{!}}-
{{!}}<code>designer.grafana.labels</code>
{{!}}Labels that have to be added to the Grafana ConfigMap.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>designer.grafana.annotations</code>
{{!}}Annotations that have to be added to the Grafana ConfigMap.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>annotations</code>
{{!}}Enables Kubernetes Annotations and adds it to all the resources that have been created.
For more information, refer to the [https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/ Annotations] topic in the Kubernetes documentation site.
{{!}}Optional
{{!}}<code>{}</code>
{{!}}-
{{!}}<code>labels</code>
{{!}}Any custom labels can be configured here. It is a key and value pair, for example, key:"value". These labels are added to all resources.
{{!}}Optional
{{!}}<code>{}</code>
{{!}}-
{{!}}<code>podLabels</code>
{{!}}Labels that will be added to all application pods.
{{!}}Optional
{{!}}<code>{}</code>
{{!}}-
{{!}}<code>podAnnotations</code>
{{!}}Annotations that will be added to all application pods.
{{!}}Optional
{{!}}<code>{}</code>
{{!}}}

====4.1.1 Designer ConfigMap settings====
The following table provides information on the environment variables and service-level settings stored in the Designer ConfigMap.
{{{!}} class="wikitable"
{{!}}Parameter
{{!}}Description
{{!}}Mandatory?
{{!}}Default Value
{{!}}-
{{!}}<code>designer.designerConfig.create</code>
{{!}}This enables providing environment variables as an input to the Designer pods. It uses a ConfigMap to store the environment variables.
{{!}}Mandatory
{{!}}<code>true</code>
{{!}}-
{{!}}<code>designer.designerConfig.envs.DES_PORT</code>
{{!}}Designer port for container (<code>port</code> in flowsettings.json).
{{!}}Mandatory
{{!}}<code>8888</code>
{{!}}-
{{!}}<code>designer.designerConfig.envs.DES_APPSERVER_HOST</code>
{{!}}DAS hostname (<code>applicationHost</code> in flowsettings.json).
{{!}}Mandatory
{{!}}<code>das</code>
{{!}}-
{{!}}<code>designer.designerConfig.envs.DES_APPSERVER_PORT</code>
{{!}}DAS port (<code>applicationPort</code> in flowsettings.json).
{{!}}Mandatory
{{!}}<code>80</code>
{{!}}-
{{!}}<code>designer.designerConfig.envs.DES_DEPLOY_URL</code>
{{!}}This is normally not changed. It is the relative path to the workspace on DAS. The default value <code>/workspaces</code> should be used always (<code>deployURL</code> in flowsettings.json).
{{!}}Mandatory
{{!}}<code>/workspaces</code>
{{!}}-
{{!}}<code>designer.designerConfig.envs.DES_USE_HTCC</code>
{{!}}Set to <code>true</code> so Designer works with GWS. If set to <code>false</code>, Designer defaults to a local mode and may be used temporarily if GWS is unavailable (<code>usehtcc</code> in flowsettings.json).
{{!}}Mandatory
{{!}}<code>false</code>
{{!}}-
{{!}}<code>designer.designerConfig.envs.DES_HTCC_SERVER</code>
{{!}}GWS server host (<code>htccserver</code> in flowsettings.json). For example, [http://gws.genhtcc.com/ gws.genhtcc.com].
{{!}}Mandatory
{{!}}
{{!}}-
{{!}}<code>designer.designerConfig.envs.DES_HTCC_PORT</code>
{{!}}GWS server port (<code>htccport</code> in flowsettings.json). For example, <code>80</code>.
{{!}}Mandatory
{{!}}
{{!}}-
{{!}}<code>designer.designerConfig.envs.DES_ENABLE_ANALYTICS</code>
{{!}}To enable or disable Designer Analytics (<code>enableAnalytics</code> in flowsettings.json).
{{!}}Optional
{{!}}<code>false</code>
{{!}}-
{{!}}<code>designer.designerConfig.envs.DES_ES_URL</code>
{{!}}Elasticsearch URL (<code>esUrl</code> in flowsettings.json). For example, [http://designer-es-client-service:9200/ http://es-service:9200].
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>designer.designerConfig.envs.DES_ES_SERVER</code>
{{!}}Elasticsearch Server Host Name (<code>esServer</code> in flowsettings.json). For example, <code>es-service</code>).
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>designer.designerConfig.envs.DES_ES_PORT</code>
{{!}}Elasticsearch port (<code>esPort</code> in flowsettings.json). For example, <code>9200</code>.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>designer.designerConfig.envs.DES_FILE_LOGGING_ENABLED</code>
{{!}}Enable file logging. If not enabled, Designer will create only verbose logs.
{{!}}Mandatory
{{!}}<code>false</code> 
{{!}}-
{{!}}<code>designer.designerFlowSettings.create</code>
{{!}}Set to <code>true</code> to include the contents of the flowsettings.yaml file in a separate ConfigMap.
{{!}}Optional
{{!}}<code>false</code>
{{!}}-
{{!}}<code>designer.designerFlowSettings.envs</code>
{{!}}The flowsettings.yaml file should contain these keys, so that the file's contents will be included in the ConfigMap. Refer to the ''Updating the flowsettings file'' section under ''9. Post deployment procedures'' for more information on this.
{{!}}Optional
{{!}}
{{!}}}

===4.2 DAS deployment settings===
The following table provides information on the DAS deployment settings. These settings are configured in the '''das-values.yaml''' file.
DAS Deployment Settings

{{{!}} class="wikitable"
{{!}}Parameter
{{!}}Description
{{!}}Mandatory?
{{!}}Default Value
{{!}}-
{{!}}<code>das.deployment.replicaCount</code>
{{!}}Number of pods to be created.
{{!}}Mandatory
{{!}}<code>2</code>
{{!}}-
{{!}}<code>das.deployment.maxreplicaCount</code>
{{!}}The maximum number of replicas to be created. It is recommended to configure this setting if auto-scaling is used.
{{!}}Optional
{{!}}<code>10</code>
{{!}}-
{{!}}<code>das.deployment.strategy</code>
{{!}}The deployment strategy to follow. This determines which type of resources are deployed. Valid values are: <code>rollingupdate, blue-green, blue-green-ingress, blue-green-service, canary</code>.

*'''rollingupdate''' - default Kubernetes update strategy where resources will be updated using the rolling update strategy.
*'''blue-green''' - for deploying and upgrading the DAS service using the blue-green strategy.
*'''blue-green-ingress''' - for the blue-green upgrade, this is to create an ingress for the first time.
*'''blue-green-service''' - for the blue-green upgrade, this is to create a service for the first time, and update the service during a service cutover.
*'''canary''' - to deploy canary pods along with the blue-green pods.
{{!}}Mandatory
{{!}}<code>rollingupdate</code>
{{!}}-
{{!}}<code>das.deployment.color</code>
{{!}}This is to deploy/upgrade the DAS service using the blue-green upgrade strategy. Valid values are: <code>blue, green</code>.
{{!}}Mandatory for <code>blue-green</code> and <code>blue-green-service</code> strategies.
{{!}}
{{!}}-
{{!}}<code>das.deployment.type</code>
{{!}}Type of Kubernetes controller. Valid value is: <code>Deployment</code>
*'''Deployment''' - if the Designer workspace is stored in the local filesystem (same network where Designer is running) and mounted as NFS.
{{!}}Optional
{{!}}<code>StatefulSet</code>
{{!}}-
{{!}}<code>das.image.repository</code>
{{!}}Docker repository that contains the images for DAS.
{{!}}Mandatory
{{!}}
{{!}}-
{{!}}<code>das.image.tag</code>
{{!}}DAS image version.
{{!}}Mandatory
{{!}}
{{!}}-
{{!}}<code>das.image.pullPolicy</code>
{{!}}DAS image pull policy (imagePullPolicy). Valid values are: <Code>Always, IfNotPresent, Never</Code>.

*'''Always''' - always pull the image.
*'''IfNotPresent''' - pull the image only if it does not already exist on the node.
*'''Never''' - never pull the image.
{{!}}Optional
{{!}}<code>IfNotPresent</code>
{{!}}-
{{!}}<code>das.image.imagePullSecrets</code>
{{!}}Secret name containing the credentials for authenticating access to the Docker repository.
{{!}}Mandatory
{{!}}
{{!}}-
{{!}}<code>das.podVolumes</code>
{{!}}Provides the name of the volume and name of the persistent volume claim to be attached to the pods
{{!}}Mandatory
{{!}}
<source>das:
podVolumes:
- name: workspace
persistentVolumeClaim:
claimName: designer-managed-disk
- name: logs
persistentVolumeClaim:
claimName: designer-logs</source>
{{!}}-
{{!}}<code>das.volumes.podPvc.create</code>
{{!}}This volume is usually created to mount a local disk to a DAS container for syncing data in case cloud storage is used for storing Designer files. This value has to be <code>true</code> or <code>false</code> depending on whether the local disk is needed or not
{{!}}Optional
{{!}}<code>false</code>
{{!}}-
{{!}}<code>das.volumes.podPvc.mountPath</code>
{{!}}The path where the workspace volume is to be mounted inside the DAS container.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>das.volumes.podPvc.claim</code>
{{!}}Persistent volume claim name for the volume.
{{!}}Optional
{{!}}<code>local-workspace</code>
{{!}}-
{{!}}<code>das.volumes.podPvc.claimSize</code>
{{!}}Size of the persistent volume claim for the pod.
The persistent volume must be equal to or greater than this size.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>das.volumes.podPvc.storageClass</code>
{{!}}storageClassName provided in the persistent volume that is created for DAS (example, '''nfs''').
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>das.volumes.podPvc.accessModes</code>
{{!}}The read/write priveleges and mount priveleges of the volume claim with respect to the nodes. Valid types are: <code>ReadWriteOnce, ReadOnlyMany, ReadWriteMany</code>.

*'''ReadWriteOnce''' - the volume can be mounted as read-write by a single node.
*'''ReadOnlyMany''' - the volume can be mounted as read-only by many nodes.
*'''ReadWriteMany''' - the volume can be mounted as read-write by many nodes.

For more information, refer to the [https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes access modes] topic in the Kubernetes documentation site.
{{!}}Optional
{{!}}<code>ReadWriteOnce</code>
{{!}}-
{{!}}<code>das.volumeMounts</code>
{{!}}The name of the volume and the mount path to be used by the pods.
{{!}}Mandatory
{{!}}
<source>volumeMounts:
- mountPath: /das/www/workspaces
name: workspace
- mountPath: /das/log
name: logs</source>
{{!}}-
{{!}}<code>das.dasSecrets.enabled</code>
{{!}}Set to <code>true</code> if Kubernetes secrets must be created to store keys/credentials/tokens.
{{!}}Optional
{{!}}<code>false</code>
{{!}}-
{{!}}<code>das.dasSecrets.secrets</code>
{{!}}Key and value pairs containing the secrets, such as a username and password.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>das.livenessProbe.path</code>
{{!}}DAS liveness probe API path.
{{!}}Mandatory
{{!}}<code>/health</code>
{{!}}-
{{!}}<code>das.livenessProbe.containerPort</code>
{{!}}Port running the container.
{{!}}Mandatory
{{!}}<code>8081</code>
{{!}}-
{{!}}<code>das.livenessProbe.startupDelay</code>
{{!}}The liveness probe will be started after a given delay as specified here.
{{!}}Mandatory
{{!}}<code>10</code>
{{!}}-
{{!}}<code>das.livenessProbe.checkInterval</code>
{{!}}The interval between each liveness probe request.
{{!}}Mandatory
{{!}}<code>5</code>
{{!}}-
{{!}}<code>das.livenessProbe.failureCount</code>
{{!}}Number of liveness probe failures after which, to mark the container as unstable or restart.
{{!}}Mandatory
{{!}}<code>3</code>
{{!}}-
{{!}}<code>das.readinessProbe.path</code>
{{!}}DAS readiness probe API path.
{{!}}Mandatory
{{!}}<code>/health</code>
{{!}}-
{{!}}<code>das.readinessProbe.containerPort</code>
{{!}}Port running the container.
{{!}}Mandatory
{{!}}<code>8081</code>
{{!}}-
{{!}}<code>das.readinessProbe.startupDelay</code>
{{!}}The readiness probe will be started after a given delay as specified here.
{{!}}Mandatory
{{!}}<code>10</code>
{{!}}-
{{!}}<code>das.readinessProbe.checkInterval</code>
{{!}}The interval between each readiness probe request.
{{!}}Mandatory
{{!}}<code>5</code>
{{!}}-
{{!}}<code>das.readinessProbe.failureCount</code>
{{!}}Number of readiness probe failures after which, to mark the container as unstable or restart.
{{!}}Mandatory
{{!}}<code>3</code>
{{!}}-
{{!}}<code>das.service.enabled</code>
{{!}}Set to <code>true</code> if the service must be created.
{{!}}Optional
{{!}}<code>true</code>
{{!}}-
{{!}}<code>das.service.type</code>
{{!}}Service type. Valid values are: <Code>ClusterIP, NodePort, LoadBalancer</Code>.
{{!}}Mandatory
{{!}}<code>NodePort</code>
{{!}}-
{{!}}<code>das.service.port</code>
{{!}}The DAS service port to be exposed in the cluster.
{{!}}Mandatory
{{!}}<code>80</code>
{{!}}-
{{!}}<code>das.service.targetPort</code>
{{!}}The DAS application port running inside the container.
{{!}}Mandatory
{{!}}<code>http</code>
{{!}}-
{{!}}<code>das.service.nodePort</code>
{{!}}Port to be exposed in case service type is <code>NodePort</code>.
{{!}}Mandatory if <code>das.service.type</code> is <code>NodePort</code>.
{{!}}<code>30280</code>
{{!}}-
{{!}}<code>das.service.termination_grace_period</code>
{{!}}The period after which Kubernetes starts to delete the pods in case of deletion.
{{!}}Optional
{{!}}<code>30</code> seconds.
{{!}}-
{{!}}<code>das.ingress.enabled</code>
{{!}}Set to <code>true</code> to enable ingress.
Ingress should be enabled for all cases except for a lab/demo setup.
{{!}}Optional
{{!}}<code>false</code>
{{!}}-
{{!}}<code>das.ingress.annotations</code>
{{!}}Annotations added for the ingress resources.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>das.ingress.paths</code>
{{!}}Ingress path.
{{!}}Optional
{{!}}<code>[/]</code>
{{!}}-
{{!}}<code>das.ingress.hosts</code>
{{!}}Hostnames to be configured in ingress for the DAS service.
{{!}}Mandatory if ingress is enabled.
{{!}}- <app1 > .example.com
{{!}}-
{{!}}<code>das.ingress.tls</code>
{{!}}TLS configuration for ingress.
{{!}}Optional
{{!}}<code>[]</code>
{{!}}-
{{!}}<code>das.resources.limits.cpu</code>
{{!}}Maximum amount of CPU that K8s allocates for the container.
{{!}}Mandatory
{{!}}600m
{{!}}-
{{!}}<code>das.resources.limits.memory</code>
{{!}}Maximum amount of memory that K8s allocates for the container.
{{!}}Mandatory
{{!}}1Gi
{{!}}-
{{!}}<code>das.resources.requests.cpu</code>
{{!}}Guaranteed CPU allocation for the container.
{{!}}Mandatory
{{!}}<code>400m</code>
{{!}}-
{{!}}<code>das.resources.requests.memory</code>
{{!}}Guaranteed memory allocation for the container.
{{!}}Mandatory
{{!}}<code>512Mi</code>
{{!}}-
{{!}}<code>das.securityContext.runAsUser</code>
{{!}}This setting controls which user ID the containers are run with and can be configured to run DAS as a non-root user. You can either use the '''Genesys''' user or arbitrary UIDs. Both are supported by the DAS base image. <code>500</code> is the ID of the Genesys user.
For more information refer to the [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ Security Context] topic in the Kubernetes documentation site.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>das.securityContext.runAsGroup</code>
{{!}}This setting controls which primary group ID the containers are run with and can be configured to run DAS as a non-root user. You can either use the '''Genesys''' userGroup (GID - <code>500</code>) or arbitrary GIDs. Both are supported by the DAS base image.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>das.nodeSelector</code>
{{!}}To allow pods to be scheduled based on the labels assigned to the nodes.
{{!}}Optional
{{!}}Default value:
<code>nodeSelector: {}</code>
Sample value:
<source>nodeSelector:
<label_key>: <label_value></source>
{{!}}-
{{!}}<code>das.affinity</code>
{{!}}The K8s standard node affinity and anti-affinity configurations can be added here. Refer to the [https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/ this] topic in the Kubernetes documentation site for sample values.
{{!}}Optional
{{!}}<code>{}</code>
{{!}}-
{{!}}<code>das.tolerations</code>
{{!}}Tolerations work with taints to ensure that pods are not scheduled on to inappropriate nodes. Refer to the [https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ Taints and Tolerations] topic in the Kubernetes documentation site for sample values.
{{!}}Optional
{{!}}<code>[]</code>
{{!}}-
{{!}}<code>das.podDisruptionBudget.enabled</code>
{{!}}Set to <code>true</code> if a pod disruption budget is to be created.
{{!}}Optional
{{!}}<code>false</code>
{{!}}-
{{!}}<code>das.podDisruptionBudget.minAvailable</code>
{{!}}The number of pods that should always be available during a disruption.
{{!}}Optional
{{!}}<code>1</code>
{{!}}-
{{!}}<code>das.dnsPolicy</code>
{{!}}The DNS policy that should be applied to the DAS pods.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>das.dnsConfig</code>
{{!}}The DNS configuration that should be applied to the DAS pods.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>das.priorityClassName</code>
{{!}}The priority class name that the pods should belong to.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>das.hpa.enabled</code>
{{!}}Set to <Code>true</Code> if a K8s Horizontal Pod Autoscaler (HPA) is to be created.
{{!}}Optional
{{!}}<code>false</code>
{{!}}-
{{!}}<code>das.hpa.targetCPUPercent</code>
{{!}}The K8s HPA controller will scale up/down pods based on the target CPU utilization percentage specified. It scale up/down pods between the range <code>deployment.replicaCount to deployment.maxReplicas</code>
{{!}}Optional
{{!}}75
{{!}}-
{{!}}<code>das.hpa.targetMemoryPercent</code>
{{!}}The K8s HPA controller will scale up or scale down pods based on the target CPU utilization percentage specified here. It scales up or scales down pods between the range - <code>deployment.replicaCount</code> and <code>deployment.maxReplicas</code>.
{{!}}Optional
{{!}}<code>70</code>
{{!}}-
{{!}}<code>das.labels</code>
{{!}}Labels that will be added to the DAS pods.
{{!}}Optional
{{!}}<code>{}</code>
{{!}}-
{{!}}<code>das.annotations</code>
{{!}}Annotations added to the DAS pods.
{{!}}Optional
{{!}}<code>{}</code>
{{!}}-
{{!}}<code>das.prometheus.enabled</code>
{{!}}Set to <code>true</code> if Prometheus metrics must be enabled.
{{!}}Optional
{{!}}<code>false</code>
{{!}}-
{{!}}<code>das.prometheus.tagName</code>
{{!}}Label key assigned to the pods/service to filter out.
{{!}}Optional
{{!}}<code>service</code>
{{!}}-
{{!}}<code>das.prometheus.tagValue</code>
{{!}}Label key assigned to the pods/service to filter out.
{{!}}Optional
{{!}}<code>designer</code>
{{!}}-
{{!}}<code>das.prometheus.pod</code>
{{!}}
{{!}}Optional
{{!}}<code>❴❴pod❵❵</code>
{{!}}-
{{!}}<code>das.prometheus.instance</code>
{{!}}
{{!}}Optional
{{!}}<code>❴❴instance❵❵</code>
{{!}}-
{{!}}<code>das.prometheus.serviceMonitor.enabled</code>
{{!}}Set to <code>true<Set/code> if a service monitor resource is needed to monitor the pods through the Kubernetes service.
{{!}}Optional
{{!}}<code>false</code>
{{!}}-
{{!}}<code>das.prometheus.serviceMonitor.path</code>
{{!}}The path in which the metrics are exposed.
{{!}}Optional
{{!}}<code>/metrics</code>
{{!}}-
{{!}}<code>das.prometheus.serviceMonitor.interval</code>
{{!}}The scrape interval specified for the Prometheus server. That is, the time interval at which the Prometheus server will fetch metrics from the service.
{{!}}Optional
{{!}}<code>10s</code>
{{!}}-
{{!}}<code>das.prometheus.serviceMonitor.labels</code>
{{!}}Labels to be specified for the service monitor resource.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>das.prometheus.alerts.enabled</code>
{{!}}Set to <code>true<Set/code> if Prometheus alerts must to be created.
{{!}}Optional
{{!}}<code>false</code>
{{!}}-
{{!}}<code>das.prometheus.alerts.labels</code>
{{!}}Labels to be specified for the alerts resource.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>das.prometheus.alerts.customalerts</code>
{{!}}Any custom alerts that are created must be specified here.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>das.prometheus.alerts.<alert_names></code>
{{!}}Scenarios for which alerts need to be created.
{{!}}Optional
{{!}}
'''das.prometheus.alerts.<alert_name>'''
<source>containerRestartAlert:
interval: 3m
threshold: 5
AlertPriority: CRITICAL
MemoryUtilization:
interval: 1m
threshold: 75
AlertPriority: CRITICAL
endpointAvailable:
interval: 1m
AlertPriority: CRITICAL
CPUUtilization:
interval: 1m
threshold: 75
AlertPriority: CRITICAL
containerReadyAlert:
interval: 5m
readycount: 1
AlertPriority: CRITICAL
rsyncContainerReadyAlert:
interval: 5m
readycount: 1
AlertPriority: CRITICAL
WorkspaceUtilization:
interval: 3m
threshold: 70
workspaceClaim: designer-managed-disk
AlertPriority: CRITICAL
AbsentAlert:
interval: 1m
AlertPriority: CRITICAL
LocalWorkspaceUtilization:
interval: 3m
threshold: 70
AlertPriority: CRITICAL
Health:
interval: 3m
AlertPriority: CRITICAL
WorkspaceHealth:
interval: 3m
AlertPriority: CRITICAL
PHPHealth:
interval: 3m
AlertPriority: CRITICAL
ProxyHealth:
interval: 3m
AlertPriority: CRITICAL
PhpLatency:
interval: 1m
threshold: 10
AlertPriority: CRITICAL
HTTPLatency:
interval: 1m
threshold: 60
AlertPriority: CRITICAL
HTTP4XXCount:
interval: 5m
threshold: 100
AlertPriority: CRITICAL
HTTP5XXCount:
interval: 5m
threshold: 100
AlertPriority: CRITICAL</source>
{{!}}-
{{!}}das.grafana.enabled
{{!}}Set to <code>true</code> if the Grafana dashboard is to be created.
{{!}}Optional
{{!}}<code>true</code>
{{!}}-
{{!}}das.grafana.labels
{{!}}Labels that must be added to the Grafana ConfigMap.
{{!}}Optional
{{!}}
{{!}}-
{{!}}das.grafana.annotations
{{!}}Annotations that must be added to the Grafana ConfigMap.
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>annotations</code>
{{!}}Enables Kubernetes Annotations and adds it to all the resources that have been created.
For more information, refer to the [https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/ Annotations] topic in the Kubernetes documentation site.
{{!}}Optional
{{!}}<code>{}</code>
{{!}}-
{{!}}<code>labels</code>
{{!}}Any custom labels can be configured here. It is a key and value pair, for example, key:"value". These labels are added to all resources.
{{!}}Optional
{{!}}<code>{}</code>
{{!}}-
{{!}}<code>podLabels</code>
{{!}}Labels that will be added to all application pods.
{{!}}Optional
{{!}}<code>{}</code>
{{!}}-
{{!}}<code>podAnnotations</code>
{{!}}Annotations that will be added to all application pods.
{{!}}Optional
{{!}}<code>{}</code>
{{!}}}
====4.2.1 DAS ConfigMap settings====
{{{!}} class="wikitable"
{{!}}Parameter
{{!}}Description
{{!}}Mandatory?
{{!}}Default Value
{{!}}-
{{!}}<code>das.dasConfig.create</code>
{{!}}This setting enables providing environment variables as an input to the DAS pods. It uses a ConfigMap to store the environment variables.
{{!}}Mandatory
{{!}}<code>true</code>
{{!}}-
{{!}}<code>das.dasConfig.envs.DAS_FILE_LOGGING_ENABLED</code>
{{!}}Enables file logging. DAS supports only std out logging. This should always be set to <code>false</code>.
{{!}}Mandatory
{{!}}<code>false</code>
{{!}}-
{{!}}<code>das.dasConfig.envs.DAS_LOG_LEVEL</code>
{{!}}Enables log levels. Valid values are: <code>FATAL, ERROR, WARN, INFO, DEBUG, TRACE</code>.
{{!}}Optional
{{!}}<code>DEBUG</code>
{{!}}-
{{!}}<code>das.dasConfig.envs.DAS_STDOUT_LOGGING_ENABLE</code>
{{!}}Enables standard output console logging.
{{!}}Mandatory
{{!}}<code>true</code>
{{!}}-
{{!}}<code>das.dasConfig.envs.DAS_SERVICES_ELASTICSEARCH_ENABLED</code>
{{!}}To enable Designer Analytics. This configuration is required for DAS to initialize ES templates.
{{!}}Optional
{{!}}<code>false</code>
{{!}}-
{{!}}<code>das.dasConfig.envs.DAS_SERVICES_ELASTICSEARCH_HOST</code>
{{!}}Elasticsearch server host name with http:// prefix. For example, [http://es-service/ http://es-service].
{{!}}Optional
{{!}}
{{!}}-
{{!}}<code>das.dasConfig.envs.DAS_SERVICES_ELASTICSEARCH_PORT</code>
{{!}}Elasticsearch port. For example, <code>80</code>.
{{!}}Optional
{{!}}
{{!}}}
|Status=No
}}{{Section
|sectionHeading=5. Post deployment Designer configuration settings
|anchor=postdepconf
|alignment=Vertical
|structuredtext=Post deployment, Designer configuration is managed from the following 3 locations:

===5.1 Flow settings===
Flow Settings is used for controlling global Designer settings that are applicable to all tenants and it contains bootstrap configuration settings such as port, GWS info, and DAS URL.

Configuration path - <code>/workspace/designer/flowsettings.json</code>.

This will be configured using the helm install. Refer to the ''Updating the flowsettings file'' section under ''9. Post deployment procedures'' for more information on updating the '''flowsettings.json''' file.

===5.2 Tenant settings===
These are tenant specific settings if the Designer service is configured with multi-tenancy .

Configuration path - <code>workspace/<contactcenter-Id>/config/tenantsettings.json</code>.

The user should logout and log back in after any changes to the '''tenantsettings.json''' file. The Designer UI will continue to show the older features until the user logs out and logs back in.

Tenant specific settings are configured by directly editing the file in the above path.

===5.3 DesignerEnv transaction list===
The '''DesignerEnv''' transaction list is available in Configuration Server (<code>Tenant/Transactions/DesignerEnv)</code>. This is mostly used to control the run-time settings. Any change to the '''DesignerEnv''' transaction list does not require the application to be published again or a new build for the application.

The user should log out and log back in for the changes to reflect in the Designer UI.

The '''DesignerEnv''' transaction list is configured using Agent Setup.

===5.4 Post deployment configuration settings reference table===
{{{!}} class="wikitable"
{{!}}-
{{!}} colspan="6"{{!}}'''Category: Analytics'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>enableAnalytics</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}This flag enables or disables the analytics feature.
{{!}}
Sample value: <code>true</code> Default value: <code>false</code>
{{!}}-
{{!}}<code>esUrl</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}Elasticsearch URL
{{!}}
Sample value: [http://es-spot.usw1.genhtcc.com/ http://es-spot.usw1.genhtcc.com:80]
{{!}}-
{{!}}<code>esServer</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}Elasticsearch server host name (for example, <code>es-service</code>).
{{!}}Sample value: [http://es-spot.usw1.genhtcc.com/ es-spot.usw1.genhtcc.com]
{{!}}-
{{!}}<code>esPort</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}Elasticsearch port.
{{!}}Sample value: <code>80</code>
{{!}}-
{{!}}<code>ReportingURL</code> (optional)
{{!}}No
{{!}}No
{{!}}Yes 
Section: <code>reporting</code>
{{!}}URL of Elasticsearch where Designer applications will report data.
{{!}}
Sample value: [http://es-spot.usw1.genhtcc.com/ http://es-spot.usw1.genhtcc.com:80]
{{!}}-
{{!}}<code>esMaxQueryDuration</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}The maximum time range (in days) to query in Designer Analytics. Each day's data is stored in a separate index in Elasticsearch.
{{!}}
Sample value: <code>90</code> Default value: <code>90</code>
{{!}}-
{{!}}<code>sdrMaxObjCount</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}The maximum count of nested type objects that will be captured in SDRs. When set to -1, which is the default value, no objects will be trimmed. All the ''milestones'' or ''activities'' visited in runtime are expected to be captured in an SDR.
{{!}}
Sample value: <code>20</code>
{{!}}-
{{!}}<code>SdrTraceLevel</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}} It controls the level of SDR detail that is recorded by <code>blocks</code> array for each application. Currently, the valid {{!}}Value are:

*'''100''' — Debug level and up. Currently, there are no Debug messages.
*'''200''' — Standard level and up. This setting will show all blocks that are entered during a call in the <code>blocks</code> array.
*'''300''' — Important level and up. This setting filters out all blocks from the <code>blocks</code> array, except those containing data that will change from call to call (such as the Menu block and User Input block).
{{!}}
Sample value: <code>300</code> Default value: <code>300</code>
{{!}}-
{{!}} colspan="6"{{!}}'''Category: Audit'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>enableESAuditLogs</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}Enable or disable audit logs captured in Elasticsearch.
{{!}}
Sample value: <code>false</code> Default value: <code>false</code>
{{!}}-
{{!}}<code>enableFSAuditLogs</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}Enable or Disable audit logs captured in the file system under the '''logs''' directory or in standard output.
{{!}}
Sample value: <code>true</code> Default value: <code>true</code>
{{!}}-
{{!}}<code>maxAppSizeCompare</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}The maximum size of data object for which a difference will be captured in the audit logs, value in bytes. That is, the difference between the Designer object's old value and new value.
{{!}}
Sample value: <code>1000000</code> Default value: <code>1000000</code>
{{!}}-
{{!}}<code>enableReadAuditLogs</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}Control whether reading of Designer objects is captured in audit trails. If enabled any Designer object viewed in the UI will be recorded in the audit logs.
{{!}}
Sample value: <code>false</code> Default value: <code>false</code>
{{!}}-
{{!}} colspan="6"{{!}}'''Category: Authorization'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>disableRBAC</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}Controls if Designer reads and enforces permissions associated with the logged in user's roles.
{{!}}
Sample value: <code>false</code> Default value: <code>false</code>
{{!}}-
{{!}}<code>rbacSection</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}In a Role object, the name of the section within the Annex where the privileges are stored.
{{!}}
Sample value: <code>CfgGenesysAdministratorServer</code> Default value: <code>CfgGenesysAdministratorServer</code>
{{!}}-
{{!}}<code>disablePBAC</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}Controls if Designer allows partitioning of the Designer workspace and restricts a user's access to Designer objects in the user's partitions.
{{!}}
Sample value: <code>false</code> Default value: <code>false</code>
{{!}}-
{{!}} colspan="6"{{!}}'''Category: Collaboration'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>locking</code> (optional)
{{!}}Yes
{{!}}No
{{!}}No
{{!}}The type of locking used, in an editing session for applications, modules, or data tables. Valid values are: <code>file, redis, none</code>.

*'''none''' - resources are not locked and can be edited simultaneously by multiple users which can result in one user overwriting another user's changes.
*'''file''' - uses files to keep track of locks and relies on shared storage (for example, NFS) to make lock files available to each Designer pod. Lock files are stored in the same location as the user's Designer workspace.
*'''redis''' - uses Redis for storing resource locks and is recommended for production environments.
{{!}}
Sample value: <code>file</code> Default value: <code>file</code>
{{!}}-
{{!}} colspan="6"{{!}}'''Category: DAS'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>applicationHost</code> (mandatory)
{{!}}Yes
{{!}}No
{{!}}No
{{!}}The server name Designer uses to generate the URL to the application. ORS and MCP fetch the application code and other resources from this URL.
{{!}}
Sample value: <code>das.usw1.genhtcc.com</code> Default value: <code>localhost</code>
{{!}}-
{{!}}<code>applicationPort</code>
{{!}}Yes
{{!}}No
{{!}}No
{{!}}The corresponding port to be used with applicationHost.
{{!}}
Sample value: <code>80</code> Default value: <code>80</code>
{{!}}-
{{!}}<code>deployURL</code>
{{!}}Yes
{{!}}No
{{!}}No
{{!}}This is normally not changed. It is the relative path to the workspace on DAS.
{{!}}
Sample value: <code>/workspace</code> Default value: <code>/workspace</code>
{{!}}-
{{!}} colspan="6"{{!}}'''Category: Digital'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>rootsSRL</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}If specified, this is used to filter which Root Categories to display when selecting Standard Responses.
{{!}}
Sample value: Any REGular EXpression (REGEX).
{{!}}-
{{!}}<code>maxFlowEntryCount</code> (optional)
{{!}}Yes
{{!}}No
{{!}}Yes 
Section: <code>flowsettings</code>
{{!}}Specify how many times the same application can process a specific digital interaction.
{{!}}
Sample value: <code>20</code> Default value: <code>20</code>
{{!}}-
{{!}} colspan="6"{{!}}'''Category: External APIs'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>httpProxy</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}Yes 
Secion: <code>flowsettings</code>
{{!}}Specify the proxy used for external requests and nexus API calls (if <code>enable_proxy</code> is <code>true</code>).
{{!}}
Sample value: [http://[http://vpcproxy-000-int.geo.genprim.com/ vpcproxy-000-int.geo.genprim.com]:8080
{{!}}-
{{!}}<code>redundantHttpProxy</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}Yes 
Section: <code>flowsettings</code>
{{!}}Specify the backup proxy used for external requests and nexus API calls (if <code>enable_proxy</code> is <code>true</code>), when httpProxy is down.
{{!}}
Sample value: [http://[http://vpcproxy-000-int.geo.genprim.com/ vpcproxy-001-int.geo.genprim.com]:8080
{{!}}-
{{!}} colspan="6"{{!}}'''Category: Features'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>features</code>
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}This is an object. See the '''5.5 Features''' section for a list of supported features.
{{!}}
Default value:
<source>{
nexus: true,
enableBulkAudioImport: true
}</source>
{{!}}-
{{!}} colspan="6"{{!}}'''Category: GWS'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>usehtcc</code>
{{!}}Yes
{{!}}No
{{!}}No
{{!}}Set to <code>true</code> so that Designer works with GWS. If set to <code>false</code>, Designer defaults to a local mode and may be used temporarily if GWS is unavailable.
{{!}}
Sample value: <code>true</code> Default value: <code>false</code>
{{!}}-
{{!}}<code>htccServer</code>
{{!}}Yes
{{!}}No
{{!}}No
{{!}}GWS Server
{{!}}
Sample value: [http://gws-usw1-int.genhtcc.com/ gws-usw1-int.genhtcc.com] Default value: [http://gws-usw1-int.genhtcc.com/ gws-usw1-int.genhtcc.com]
{{!}}-
{{!}}<code>htccport</code>
{{!}}Yes
{{!}}No
{{!}}No
{{!}}GWS port.
{{!}}
Sample value: <code>80</code> Default value: <code>80</code>
{{!}}-
{{!}}<code>ssoLoginUrl</code>
{{!}}Yes
{{!}}No
{{!}}No
{{!}}URL of GWS authentication UI. Designer redirects to this URL for authentication.
{{!}}
Sample value: [https://gws-usw1.genhtcc.com/ https://gws-usw1.genhtcc.com] Default value: [https://gws-usw1.genhtcc.com/ https://gws-usw1.genhtcc.com]
{{!}}-
{{!}}<code>maxConcurrentHTCCRequest</code> (optional)
{{!}}Yes
{{!}}No
{{!}}No
{{!}}For batch operations to GWS, the max number of concurrent requests that Designer will send to GWS.
{{!}}
Sample value: <code>5</code> Default value: <code>5</code>
{{!}}-
{{!}}<code>batchOperationResultTTL</code> (optional)
{{!}}Yes
{{!}}No
{{!}}No
{{!}}For batch operations to GWS, the time, in milliseconds, for which duration Designer stores the results of a batch operation on the server, before deleting them.
{{!}}
Sample value: <code>100000</code> Default value: <code>100000</code>
{{!}}-
{{!}} colspan="6"{{!}}'''Category: Help'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>docsMicroserviceURL</code> (optional)
{{!}}Yes
{{!}}No
{{!}}No
{{!}}URL for Designer documentation.
{{!}}
Default value: https://docs.genesys.com/Documentation/PSAAS/Public/Administrator/Designer
{{!}}-
{{!}} colspan="6"{{!}}'''Category: IVR'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>recordingType</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}Specify the recording type to be used in Record block. Set as <code>GIR</code>. If the option is missing or blank, <code>Full Call Recording</code> type will be used.
{{!}}
Sample value: <code>GIR</code> Default value: <code>GIR</code>
{{!}}-
{{!}} colspan="6"{{!}}'''Category: Logging'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}
<source>
logging: {
designer: { level:
debug },
audit: { level: trace},
auditdebug: { level: debug },
cli: { level: debug }
}
</source>
(optional)
{{!}}Yes
{{!}}No
{{!}}No
{{!}}Specify Designer log levels. Each field has valid values: <code>trace, debug, info, warn, error, or fatal</code>.

*'''designer''' - log level of Designer.
*'''audit''' - log level of audit.
*'''auditdebug''' - log level of audit debug, this will log detailed audit information.
*'''cli''' - log level for cli commands executed on Designer.
{{!}}
Sample value: 
<source>logging: {
designer: { level: debug},
audit: { level: trace },
auditdebug: { level: debug},
cli: { level: debug }
}
</source> Default value: 
<source>
logging: {
designer: { level: debug },
audit: { level: trace },
auditdebug: { level: debug },
cli: { level: debug }
}
</source>
{{!}}-
{{!}} colspan="6"{{!}}'''Category: Nexus'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>url</code> (optional)
{{!}}No
{{!}}No
{{!}}Yes 
Section: <code>nexus</code>
{{!}}URL of Nexus that typically includes the API version path. For example, https://nexus-server/nexus/api/v3.
{{!}}
Default value: [http://nex-dev.usw1.genhtcc.com/ http://nex-dev.usw1.genhtcc.com]
{{!}}-
{{!}}<code>password</code> (optional)
{{!}}No
{{!}}No
{{!}}Yes 
Section: <code>nexus</code>
{{!}}The Nexus x-api-key created by Nexus deployment.
{{!}}
Default value: <code>dc4qeiro13nsof569dfn234smf</code>
{{!}}-
{{!}}<code>enable_proxy</code> (optional)
{{!}}No
{{!}}No
{{!}}Yes 
Section: <code>nexus</code>
{{!}}Boolean value to indicate if httpProxy is used to reach Nexus.
Default value: <code>false</code>
{{!}}-
{{!}}profile (optional)
{{!}}No
{{!}}No
{{!}}Yes 
Section: <code>nexus</code>
{{!}}Enable Contact Identification via Nexus (for example, to enable Last Called Agent routing).
{{!}}
{{!}}-
{{!}} colspan="6"{{!}}'''Category: Process'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>port</code>
{{!}}Yes
{{!}}No
{{!}}No
{{!}}Designer process port in the container. Normally, the default value should be left as is.
{{!}}
Sample value: <code>8888</code> Defualt value: <code>3000</code>
{{!}}-
{{!}} colspan="6"{{!}}'''Category: Provisioning'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>primarySwitch</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}Specify the primary switch name if more than one switch is defined for the tenant. Designer fetches and works with route points from this switch.
{{!}}
Default value: <code>us-west-1</code>
{{!}}-
{{!}} colspan="6"{{!}}'''Category: Routing'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>ewtRefreshTimeout</code> (optional)
{{!}}NO
{{!}}No
{{!}}Yes 
Section: <code>flowsettings</code>
{{!}}Specify the interval (in seconds) at which to refresh the Estimated Waiting Time when routing an interaction.
{{!}}
Sample value: <code>5</code> Default value: <code>1</code>
{{!}}-
{{!}} colspan="6"{{!}}'''Category: Redis'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}
<source>redis: {
host: "",
port: "",
tlsEnabled: true,
lockTimeout: 120,
listTimeout: 1800
}
</source> (optional)
{{!}}Yes
{{!}}No
{{!}}No
{{!}}Used by Designer for resource index caching and multi-user collaboration locks on Designer resources.
It is a separate object that contains:

*'''host''' - Redis host name.
*'''port''' - Redis port.
*'''tlsEnabled''' - TLS enabled or not.
*'''lockTimeout''' - Timeout, in seconds, before a resource lock is released for an editing session of applications, modules, or data tables.
*'''listTimeout''' - The cache expiry timeout (in seconds) of the application list and shared modules list. By default, it is 30 minutes. That is, any new application/modules created in the UI will be seen in the listing page after 30 mins. It can be reduced to a smaller value. This is to improve the page loading performance of the Applications and Shared Modules page. A better performance is achieved with a higher value.
{{!}}
Sample value: 
<source>
redis: {
host: "",
port: "",
tlsEnabled: true,
lockTimeout: 120,
listTimeout: 1800
}
</source> Default value: 
<source>
redis: {
host: redis.server.genhtcc.com,
port: 6379,
tlsEnabled: true,
lockTimeout: 120,
listTimeout: 1800
}
</source>
{{!}}-
{{!}} colspan="6"{{!}}'''Category: Security'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>zipFileSizeLimitInMegaBytes</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}Defines the maximum zipFile size limit (in megabytes) during bulk audio import.
{{!}}
Sample value: <code>50</code>
{{!}}-
{{!}}<code>disableCSRF</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}Disable CSRF attack protection. For more information, refer to this [http://cwe.mitre.org/data/definitions/352.html topic] in the CWE site.
By default, CSRF attack protection is enabled. It can be disabled by setting this flag to <code>true</code>.
{{!}}
Sample value: <code>false</code> Default value: <code>false</code>
{{!}}-
{{!}}<code>disableSecureCookie</code> (optional)
{{!}}Yes
{{!}}No
{{!}}No
{{!}}Disables the secure cookies header.
{{!}}
Sample value: <code>false</code> Default value: <code>false</code>
{{!}}-
{{!}} colspan="6"{{!}}'''Category: Session'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>idleTimeout</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}Idle timeout, in seconds, before a user session is terminated while editing applications, modules, or data tables.
{{!}}
Sample value: <code>840</code> Default value: <code>840</code>
{{!}}-
{{!}}<code>lockTimeout</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}Timeout, in seconds, before a resource lock is released, for an editing session of applications, modules, or data tables.
{{!}}
Sample value: <code>120</code> Default value: <code>120</code>
{{!}}-
{{!}}<code>lockKeepalive</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}Interval, in seconds, before the client sends a ping to the server, to refresh the lock for an editing session of applications, modules, or data tables.
{{!}}
Sample value: <code>15</code> Default value: <code>15</code>
{{!}}-
{{!}} colspan="6"{{!}}'''Category: Workflow'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}Description
{{!}}Value
{{!}}-
{{!}}<code>maxBuilds</code> (optional)
{{!}}Yes
{{!}}Yes
{{!}}No
{{!}}Specify the maximum number of builds allowed per application.
{{!}}
Sample value: <code>20</code> Default value: <code>20</code>
{{!}}-
{{!}}<code>enablePTE</code> (optional)
{{!}}No
{{!}}No
{{!}}Yes 
Section: <code>flowsettings</code>
{{!}}Boolean value to indicate if PTE objects are enabled at runtime.
{{!}}
Sample value: <code>true</code> Default value: <code>false</code>
{{!}}}
===5.5 Features===
The features specified in this section are configured under the <code>features</code> object in the '''flowsettings.json''' file or the '''tenantsettings.json''' file.

For example,
<source>
"features": {
"nexus": true,
..
}</source>
{{NoteFormat|These features are configured only in the '''flowsettings.json''' file and the '''tenantsettings.json''' file, and not in the '''DesignerEnv''' transaction list.|}}
{{{!}} class="wikitable"
{{!}}Category
{{!}}Feature Setting Name
{{!}}Mandatory
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}Description
{{!}}Default Value
{{!}}-
{{!}} rowspan="3"{{!}}Audio
{{!}}<code>enableBulkAudioImport</code>
{{!}}Optional
{{!}}Yes
{{!}}Yes
{{!}}Enable/disable the bulk audio import feature.
{{!}}<code>false</code>
{{!}}-
{{!}}<code>grammarValidation</code>
{{!}}Optional
{{!}}Yes
{{!}}yes
{{!}}If this feature is enabled, Designer will validate invalid grammar files during grammar upload and you can upload only valid grammar files (GRXML or Nuance compiled binary grammar files).
{{!}}<code>false</code>
{{!}}-
{{!}}<code>externalAudioSupport</code>
{{!}}Optional
{{!}}Yes
{{!}}Yes
{{!}}If this feature is enabled, a new audio type, External Audio, is available in the Play Message block. It accepts a single variable that contains a URL to the audio resource. MCP will fetch this resource directly and play it. The only supported value of '''Play As''' is ''Audio URI''. There is no automatic language switching for this audio type.
{{!}}<code>false</code>
{{!}}-
{{!}}Nexus
{{!}}<code>nexus</code>
{{!}}Optional
{{!}}Yes
{{!}}Yes
{{!}}Enable/disable the Nexus feature.
{{!}}<code>false</code>
{{!}}-
{{!}}Survey
{{!}}<code>survey</code>
{{!}}Optional
{{!}}Yes
{{!}}Yes
{{!}}Enable/disable the survey feature.
{{!}}<code>true</code>
{{!}}-
{{!}} rowspan="2"{{!}}UI Plugins
{{!}}<code>plugins</code>
{{!}}Optional
{{!}}Yes
{{!}}Yes
{{!}}Plugin configuration details. 
(Steps are given below the table.)
{{!}}{}
{{!}}-
{{!}}<code>plugins</code>
{{!}}Optional
{{!}}Yes
{{!}}Yes
{{!}}Enable or disable the plugin feature.
{{!}}<code>false</code>
{{!}}-
{{!}}Milestone
{{!}}<code>enableImplicitModuleMilestones</code>
{{!}}Optional
{{!}}Yes
{{!}}Yes
{{!}}Enable reporting each Shared Module call as an internal milestone. If disabled, Shared Module calls will not generate a milestone.
{{!}}<code>false</code>
{{!}}-
{{!}}Bots
{{!}}<code>enableDialogFlowCXBot</code>
{{!}}Optional
{{!}}Yes
{{!}}Yes
{{!}}When enabled, Dialogflow CX bot type is added to the bot registry and available for selection in the '''Bot provider''' drop-down when you configure a new bot.
{{!}}<code>false</code>
{{!}}}
===5.6 Adding a UI plugin to Designer===
#Add the <code>plugins</code> array object in the '''flowsettings.json''' file (''/ofs/designer/flowsettings.json''). The <code>plugins</code> object contains all the input properties for the plugin app. This is a required property. Whenever there is a change in this object, refresh the browser for the changes to take effect. Example:<source>"plugins": [
{
"url": "http://genesysexample.com/",
"displayName": "Nexus PII Management",
"placement": "messageCollections",
"id": "nexuspii",
"mappings": {
"prod": {
"G1-AUS4": "https://genesysexample.com/admin/ux"
},
"staging": {
"G1-USW1": "http://genesysexample.com/"
},
}
},
{
...
}]</source>
#Add the <code>csplist</code> array object in the '''flowsettings.json''' file (''/ofs/designer/flowsettings.json''). The <code>cspList</code> object contains the URL forms to be allowed by Designer's security policy. This is a required property. Whenever there is a change in this object, re-start the node container for the changes to take effect. Example: If the URL is <code>http://genesysexample.com/</code>, the <code>cspList</code> would be: <code>"cspList": ["*.genexample1.com:*", "*.genexample2.com:*", "*.genexample3.com:*"]</code>
#Turn on the <code>plugins</code> and <code>nexus</code> feature flags in the Designer '''tenantSettings.json''' file (''/ofs/<tenantId>/config/tenantSettings.json''). This is a required property. Whenever there is a change in this object, log out of Designer and log in again for the changes to take effect.{{NoteFormat|If you want to enable the plugins feature for all tenants, add this feature flag in the '''flowsettings.json''' file. The feature is enabled for all the tenants under that bucket.|}}Example:<source>{
"features": {
"plugins": true,
"nexus": true
}}</source>
#Add the <code>url_<plugin-id></code> property under the <code>plugins</code> section, in Agent Setup. If there is no <code>plugins</code> section, create one. This section is for the tenant URL override. If the <code>DesignerEnv</code> setting (''Transactions/Internal/DesignerEnv'') is not provided, the plugin URL from the '''flowsettings.json''' file is considered. This is an optional property. Whenever there is a change in this object, log out of Designer and log in again for the changes to take effect. Example: <code>{"url_<plugin-id>" : "https://plugin-genesysexample.com"}</code>
|Status=No
}}
{{Section
|sectionHeading=6. Logging
|anchor=logging
|alignment=Vertical
|structuredtext=Designer and DAS support console output (stdout) logging. Genesys recommends configuring console output logging to minimize the host IOPs and PVCs consumption by using log volumes. Console output logs can be extracted using log collectors like ''fluentbit/fluentd'' and ''Elasticsearch''.

Ensure the below setttings are configured in the respective '''values.yaml''' overrides for console logging:

#Designer <code>designerEnv.envs.DES_FILE_LOGGING_ENABLED = false</code>
#DAS <code>dasEnv.envs.DAS_FILE_LOGGING_ENABLED = false</code> <code>dasEnv.envs.DAS_STDOUT_LOGGING_ENABLE = true</code>

===6.1 Log levels===
Post deployment, Designer and DAS log levels can be modified as follows:

====6.1.1 Designer====

#Configure the <code>logging</code> setting in the flowsettings override ('''flowsettings.yaml''') - Refer to the ''5.4 Post deployment configuration settings reference table'' section for option descriptions.
#Execute the steps in the ''Flowsettings.json update'' section (see ''Designer'' under ''8.8 Blue-Green deployment'') for the changes to take effect .

====6.1.2 DAS====

#Configure the <code>dasEnv.envs.DAS_LOG_LEVEL</code> setting in the Helm '''das-values.yaml''' file. Refer to section ''4.2 DAS deployment settings'' for setting descriptions.
#Execute the steps in the ''Upgrade non production color'' section (see ''DAS'' under ''8.8 Blue-Green deployment''). The same DAS version running in production can be used for the upgrade,
#Execute the steps in the ''Cutover'' section (see ''DAS'' under ''8.8 Blue-Green deployment'').
|Status=No
}}
{{Section
|sectionHeading=7. Platform / Configuration Server and GWS settings
|anchor=placonset
|alignment=Vertical
|structuredtext=This section explains the Configuration Server objects and settings required for Designer.

===7.1 Create Roles for Designer===

Designer uses roles and access groups to determine permissions associated with the logged-in user. To enable this, you must make these changes in GAX or CME.

Designer supports a number of bundled roles suitable for various levels of users.

*'''Designer Developer''' - Most users fall into this category. These users can create Designer applications, upload audio, and create business controls. They have full access to Designer Analytics.

*'''Designer Business User''' - These users cannot create objects but they can manage them (for example, upload audio, change data tables, and view analytics).

*'''Designer Analytics''' - These users only have access to Designer Analytics.

*'''Designer Admin''' - These users can set up and manage partitions associated with users and Designer objects.
*'''Designer Operations''' - Users with this role have full access to all aspects of the Designer workspace. This includes the '''Operations''' menu (normally hidden), where they can perform advanced operational and maintenance tasks.

To create these roles, import the '''.conf''' files included in the '''Designer Deployment''' package. They are located in the '''packages/roles/''' folder.

In addition, ensure the following for user accounts that need access to Designer:

*The user must have read permissions on its own Person object.
*Users must be associated with one or more roles via access groups.
*The on-Premises user must have at least read access on the user, access group(s), and roles(s).
*The access groups must have read/write permissions to the Agent Setup folders - Scripts and Transactions.

===7.2 Create the DesignerEnv transaction list===

Designer requires a transaction list for configuration purposes as described in other sections of this document. To set this up:

#Create a transaction list called '''DesignerEnv'''.
#Import the file '''configuration/DesignerEnv.conf''', located in the Designer Deployment Manifest package.
#Edit any values according to the descriptions provided in ''5.4 Post deployment configuration settings reference table''.
#Save the list.
#Ensure Designer users have at least read access to the '''DesignerEnv''' transaction list.

===7.3 Platform settings===

The platform settings listed below must be configured if the Designer application is used for voice calls.
{{{!}} class="wikitable"
{{!}}Component
{{!}}Config Key
{{!}}Value
{{!}}Description
{{!}}-
{{!}}SIP Switch -> Voip Services -> msml service
{{!}}userdata-map-format
{{!}}sip-headers-encoded
{{!}}Option needs to set to pass JSON data as user data in SIPS.
{{!}}-
{{!}}SIP Switch -> Voip Services -> msml service
{{!}}userdata-map-filter
{{!}}*
{{!}}To allow userdata passing to MSML service.
{{!}}-
{{!}} rowspan="7"{{!}}SIPServer --> TServer
{{!}}divert-on-ringing
{{!}}false
{{!}}RONA is handled by the platform.
{{!}}-
{{!}}agent-no-answer-timeout
{{!}}12
{{!}}
{{!}}-
{{!}}agent-no-answer-action
{{!}}notready
{{!}}
{{!}}-
{{!}}agent-no-answeroverflow
{{!}}""
{{!}}No value, empty.
{{!}}-
{{!}}after-routing-timeout
{{!}}24
{{!}}
{{!}}-
{{!}}sip-treatments-continuous
{{!}}true
{{!}}
{{!}}-
{{!}}msml-record-support
{{!}}true
{{!}}To allow routed calls recording via the Media Server.
{{!}}-
{{!}}Switch object annex --> gts
{{!}}ring-divert
{{!}}1
{{!}}
{{!}}-
{{!}}ORS --> orchestration
{{!}}new-session-on-reroute
{{!}}false
{{!}}Required for SIPS Default Routing ([https://intranet.genesys.com/pages/viewpage.action?pageId=55813481 Default Routing handling (Voice)]).
{{!}}-
{{!}}MCP
{{!}}[vxmli] transfer.allowed
{{!}}TRUE
{{!}}Required for Transfer block (allows VXML Transfer in MCP).
{{!}}-
{{!}}MCP
{{!}}[cpa] outbound.method
{{!}}NATIVE
{{!}}Required for Transfer block (allow CPA detection for Transfer ).
{{!}}-
{{!}}UCS
{{!}}[cview] enabled
{{!}}TRUE
{{!}}Enables Customer Context Services.
{{!}}}

===7.4 GWS configuration===

Ensure that the following steps are performed in GWS.

====7.4.1 Create Contact Center====
Create a contact center in GWS if it is not already created. Refer to the [https://docs.genesys.com/Documentation/HTCC/8.5.2/API/Welcome GWS documentation] for more information on this.
====7.4.2 Create GWS Client====
Create new GWS client credentials if they are not already created . Refer to the [https://docs.genesys.com/Documentation/HTCC/8.5.2/API/Welcome GWS documentation] for more information on this.
|Status=No
}}
{{Section
|sectionHeading=8. Deployment
|anchor=dep
|alignment=Vertical
|structuredtext=This section describes the deployment process for Designer and DAS.

===8.1 Preparation===

Before you deploy Designer and DAS using Helm charts, complete the following preparatory steps:

#Ensure the Helm client is installed.
#Set up an Ingress Controller, if not already done.
#Setup an NFS server, if not already done.
#Create Persistent Volumes - a sample YAML file is provided in the Designer manifest package.
#Download the Designer and DAS docker images and push to the local docker registry.
#Download the Designer package and extract to the current working directory.
#Configure Designer and DAS value overrides ('''designer-values.yaml''' and '''das-values.yaml'''); ensure the mandatory settings are configured. If the Blue-Green deployment process is used, Ingress settings are explained in the ''8.8 Blue-Green deployment'' section.

===8.2 Set up Ingress===
Given below are the requirements to set up an Ingress for the Designer UI:

*Cookie name - designer.session.
*Header requirements - client IP & redirect, passthrough.
*Session stickiness - enabled.
*Allowlisting - optional.
*TLS for ingress - optional (should be able to enable or disable TLS on the connection).

===8.3 Set up Application Gateway (WAF) for Designer===
Designer Ingress must be exposed to the internet using Application Gateway enabled with WAF.

When WAF is enabled, consider the following exception in the WAF rules for Designer:

*Designer sends a JSON payload with data, for example, <code>{profile . {} }</code>. Sometimes, this is detected as <code>OSFileAccessAttempt</code>, which is a false positive detection. Disable this rule if you encounter a similar issue in your WAF setup.

===8.4 Storage===
====8.4.1 Designer storage====
Designer requires storage to store designer application workspaces. Designer storage is a shared file storage that will be used by the Designer and DAS services.{{NoteFormat|This storage is critical. Ensure you take backups and snapshots at a regular interval, probably, each day.|}}A Zone-Redundant Storage system is required to replicate data from the RWX volumes and must be shared across multiple pods:

*Capacity - 1 TiB
*Tier - Premium
*Baseline IO/s - 1424
*Burst IO/s - 4000
*Egress Rate - 121.4 MiBytes/s
*Ingress Rate - 81.0 MiBytes/s

====8.4.2 Permission considerations for Designer and DAS storage====
'''NFS'''

For NFS RWX storages, the mount path should be owned by <nowiki><code>genesys:genesys</code></nowiki>, that is, <nowiki><code>500:500</code></nowiki> with <nowiki><code>0777</code></nowiki> permissions. It can be achieved by one of the below methods:

*From the NFS server, execute the '''chmod -R 777 <export_path>''' and '''chown -R 500:500''' '''<export_path>''' commands to set the required permissions.
*Create a dummy Linux based pod that mounts the NFS storage. From the pod, execute the '''chmod -R 777 <mount_path>''' and '''chown -R 500:500 <mount_path>''' commands. This sets the required permissions. However, this method might require the Linux based pods to be run as privileged.

'''SMB / CIFS'''

For SMB / CIFS based RWX storages, for instance, Azure file share, the below <nowiki><code>mountOptions</code></nowiki> must be used in the '''StorageClass''' or the '''PersistentVolume''' template:

<nowiki><code></nowiki>'''mountOptions'''<nowiki></code></nowiki><syntaxhighlight>
- dir_mode=0777
- file_mode=0777
- uid=500
- gid=500
- mfsymlinks
- cache=strict
</syntaxhighlight>

===8.5 Set up Secrets===
Secrets are required by the Designer service to connect to GWS and Redis (if you are using them).

GWS Secrets:

*GWS provides a Client ID and secrets to all clients that can be connected. You can create Secrets for the Designer client as specified in the ''Set up secrets for Designer'' section below.

Redis password:

*If Designer is connected to Redis, you must provide the Redis password to Designer to authenticate the connection.

====8.5.1 Set up Secrets for Designer====
Use the <code>designer.designerSecrets</code> parameter in the '''values.yaml''' file and configure Secrets as follows:

<source>designerSecrets:
enabled: true
secrets:
DES_GWS_CLIENT_ID: xxxx
DES_GWS_CLIENT_SECRET: xxxx
DES_REDIS_PASSWORD: xxxxx</source>

===8.6 Deployment strategies===

Designer supports the following deployment strategies:

*Rolling Update (default).
*Blue-Green (recommended).

DAS (Designer Application Server) supports the following deployment strategies:

*Rolling Update (default).
*Blue-Green (recommended).
*Canary (must be used along with Blue-Green and is recommended in production).

===8.7 Rolling Update deployment===

The rolling update deployment is the standard default deployment to Kubernetes. It works slowly, one by one, replacing pods of the previous version of your application with pods of the new version without any cluster downtime. It is the default mechanism of upgrading for both Designer and DAS.

===8.7.1 Designer===
====Initial deployment====
To perform the initial deployment for a rolling upgrade in Designer, use the Helm command given below. The values.yaml file can be created as required.

*<code>helm upgrade --install designer -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.image.tag=9.0.1xx.xx.xx</code>

The values.yaml overrides passed as an argument to the above Helm upgrade command:

<code>designer.image.tag=9.0.1xx.xx.xx</code> - This is the new Designer version to be installed, for example, <code>9.0.111.05.5</code>.

====Upgrade====
To perform an upgrade, the image version has to be upgraded in the '''designer-values.yaml''' file or can be set using the <code>--set</code> flag through the command given below. Once the '''designer-values.yaml''' file is updated, use this Helm command to perform the upgrade:

*<code>helm upgrade --install designer -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.image.tag=9.0.1xx.xx.xx</code>

The values.yaml overrides passed as an argument to the above Helm upgrade command:

<code>designer.image.tag=9.0.1xx.xx.xx</code> - This is the new Designer version to be installed, for example, <code>9.0.111.05.5</code>.

====Rollback====
To perform a rollback, the image version in the '''designer-values.yaml''' file can be downgraded. Or you can use the <code>--set</code> flag through the command given below. Once the '''designer-values.yaml''' file is updated, use this Helm command to perform the rollback:

*<code>helm upgrade --install designer -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.image.tag=9.0.1xx.xx.xx</code>

The values.yaml overrides passed as an argument to the above Helm upgrade command:

<code>designer.image.tag=9.0.1xx.xx.xx</code> - This is the Designer version to be rolled back to, for example, <code>9.0.111.05.5</code>.

===8.7.2 DAS===

====Initial deployment====
To perform the initial deployment for a rolling upgrade in DAS, use the Helm command given below. The values.yaml file can be created as required.

*<code>helm upgrade --install designer-das -f designer-das-values.yaml designer-das-100.0.112+xxxx.tgz --set das.image.tag=9.0.1xx.xx.xx</code>

The values.yaml overrides passed as an argument to the above Helm upgrade command:

<code>das.image.tag=9.0.1xx.xx.xx</code> - This is the new DAS version to be installed, for example, <code>9.0.111.05.5</code>.

====Upgrade====
To perform an upgrade, the image version has to be upgraded in the '''designer-das-values.yaml''' file or can be set using the <code>--set</code> flag through the command given below. Once the '''designer-das-values.yaml''' file is updated, use this Helm command to perform the upgrade:

*<code>helm upgrade --install designer-das -f designer-das-values.yaml designer-das-100.0.112+xxxx.tgz --set das.image.tag=9.0.1xx.xx.xx</code>

The values.yaml overrides passed as an argument to the above Helm upgrade command:

<code>das.image.tag=9.0.1xx.xx.xx</code> - This is the new DAS version to be installed, for example, <code>9.0.111.05.5</code>.

====Rollback====
To perform a rollback, the image version in the '''designer-das-values.yaml''' file can be downgraded. Or you can use the <code>--set</code> flag through the command given below. Once the '''designer-das-values.yaml''' file is updated, use this Helm command to perform the rollback:

*<code>helm upgrade --install designer-das -f designer-das-values.yaml designer-das-100.0.112+xxxx.tgz --set das.image.tag=9.0.1xx.xx.xx</code>

The values.yaml overrides passed as an argument to the above Helm upgrade command:

<code>das.image.tag=9.0.1xx.xx.xx</code> - This is the DAS version to be rolled back to, for example, <code>9.0.111.05.5</code>.

===8.8 Blue-Green deployment===

Blue-Green deployment is a release management technique that reduces risk and minimizes downtime. It uses two production environments, known as Blue and Green or active and inactive, to provide reliable testing, continuous no-outage upgrades, and instant rollbacks.When a new release needs to be rolled out, an identical deployment of the application will be created using the Helm package and after testing is completed, the traffic is moved to the newly created deployment which becomes the active environment, and the old environment becomes inactive. This ensures that a fast rollback is possible by just changing route if a new issue is found with live traffic. The old inactive deployment is removed once the new active deployment becomes stable.

===8.8.1 Designer===

Service cutover is done by updating the Ingress rules. The diagram below shows the high-level approach to how traffic can be routed to Blue and Green deployments with Ingress rules.

[[File:DesBlueGreenDep.png|border]]

====Preparation====
Before you deploy Designer using the blue-green deployment strategy, complete the following preparatory steps:

#Create 3 hostnames as given below. The blue service hostname must contain the string ''blue''. For example, ''designer.blue.example.com'' or ''designer-blue.example.com''. The green service hostname must contain the string ''green''. For example, ''designer.green.example.com'' or ''designer-green.example.com''. The blue/green services can be accessed separately with the blue/green hostnames:
#*<code>designer.example.com</code> - For the production host URL, this is used for external access.
#*<code>designer.blue.example.com</code> - For the blue service testing.
#*<code>designer.green.example.com</code> - For the green service testing. 
#Configure the hostnames in the '''designer-values.yaml''' file under <code>ingress</code>. Annotations and paths can be modified as required. <source>ingress:
enabled: true
annotations: {}
paths: [/]
hosts:
- designer.example.com
- designer.blue.example.com
- designer.green.example.com</source> 

====Initial deployment====
The resources - ingress and persistent volume claims (PVC) - must be created initially before deploying the Designer service as these resources are shared between blue/green services and they are required to be created at the very beginning of the deployment. These resources are not required for subsequent upgrades. The required values are passed using the <code>-- set</code> flag in the following steps. Values can also be directly changed in the values.yaml file.

#Create Persistent Volume Claims required for the Designer service (assuming the volume service name is <code>designer-volume</code>). <code>helm upgrade --install designer-volume -f designer-values.yaml designer-9.0.xx.tgz --set designer.deployment.strategy=blue-green-volume</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>designer.deployment.strategy=blue-green-volume</code> - This denotes that the Helm install will create a persistent volume claim in the blue/green strategy.
#Create Ingress rules for the Designer service (assuming the ingress service name will be designer-ingress): <code>helm upgrade --install designer-ingress -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.deployment.strategy=blue-green-ingress --set designer.deployment.color=green</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>designer.deployment.strategy=blue-green-ingress</code> - This denotes that the Helm install will create ingress rules for the Designer service. <code>designer.deployment.color=green</code> - This denotes that the current production (active) color is green.
#Deploy the Designer service color selected in step 2. In this case, green is selected and assuming the service name is <code>designer-green</code>: <code>helm upgrade --install designer-green -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.deployment.strategy=blue-green --set designer.image.tag=9.0.1xx.xx.xx --set designer.deployment.color=green</code>

====Upgrade====

#Identify the current production color by checking the Designer ingress rules (<code>kubectl describe ingress designer-ingress</code>). Green is the production color in the below example as the production host name points to the green service. [[File:DesUpgStep1.png|border]]
#Deploy the Designer service on to the non-production color. In the above example, blue is the non-production color and assuming the service name will be designer-blue: <code>helm upgrade --install designer-blue -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.deployment.strategy=blue-green --set designer.image.tag=9.0.1xx.xx.xx --set designer.deployment.color=blue</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>designer.deployment.strategy=blue-green</code> - This denotes that the Designer service is installed using the blue-green strategy. <code>designer.image.tag=9.0.1xx.xx.xx</code> - This denotes the new Designer version to be installed, for example, <code>9.0.116.08.12</code>. <code>designer.deployment.color=blue</code> - This denotes that the blue color service is installed. The non-production color can be accessed with the non-production host name (for example, <code>designer.blue.example.com</code>). Testing can be done using this URL.

'''NodePort Service'''

The <code>designer-green</code> release creates a service called <code>designer-green</code> and the <code>designer-blue</code> release creates a service called <code>designer-blue</code>. If you are using NodePort services, ensure that the value of <code>designer.service.nodePort</code> is not the same for both the releases. In other words, you should assign dedicated node ports for the releases. The default value for <code>designer.service.nodePort</code> is '''30180'''. If this was applied to <code>designer-green</code>, use a different value for <code>designer-blue</code>, for example, '''30181'''. Use the below helm command to achieve this:

<code>helm upgrade --install designer-blue -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.deployment.strategy=blue-green --set designer.image.tag=9.0.1xx.xx.xx --set designer.deployment.color=blue --set designer.service.nodePort=30181</code>
====Cutover====
Once testing is completed on the non-production color, traffic can be moved to the new version by updating the Ingress rules:

#Update the Designer Ingress with the new deployment color by running the following command (in this case, blue is the new deployment color, that is, the non-production color): <code>helm upgrade --install designer-ingress -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.deployment.strategy=blue-green-ingress --set designer.deployment.color=blue</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>designer.deployment.strategy=blue-green-ingress</code> - This denotes that the helm install will create ingress rules for the Designer service. <code>designer.deployment.color=blue</code> - This denotes that the current production (active) color is blue.
#Verify the ingress rules by running the following command: <code>kubectl describe ingress designer-ingress</code> The production host name must point to the new color service.

====Rollback====
If the upgrade must be rolled back, the ingress rules can be modified to point to the old deployment pods (green, in this example) by performing a cutover again.

#Perform a cutover using the following command: <code>helm upgrade --install designer-ingress -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.deployment.strategy=blue-green-ingress --set designer.deployment.color=green</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>designer.deployment.strategy=blue-green-ingress</code> - This denotes that the Helm install will create Ingress rules for the Designer service. <code>designer.deployment.color=green</code> - This denotes that the the current production (active) color is green.
#Verify the Ingress rules by running the following command: <code>kubectl describe ingress designer-ingress</code> The production host name must point to the green service.

===8.8.2 DAS===

As with Designer, the Blue-Green strategy can be adopted for DAS as well. The Blue-Green architecture used for DAS is given below. Here, the cutover mechanism is controlled by Service, the Kubernetes manifest responsible for exposing the pods. The Ingress, when enabled, will point to the appropriate service based on the URL.

[[File:DASBlueGreenDep.png|border]]

====Ingress setup====
{{NoteFormat|Ingress for DAS must be enabled only if DAS has to be reached from outside the Kubernetes cluster. If you don't intend to expose DAS outside the cluster, then ingress need not be enabled and you can skip these steps.}}

# Configure Ingress Host names for DAS.
#: Create 3 hostnames as follows: The blue service host name must contain the string ''blue''; for instance, <tt>das.blue.example.com</tt> or <tt>das-blue.example.com</tt>, The green service host name must contain the string ''green''; for instance, <tt>das.green.example.com</tt> or <tt>das-green.example.com</tt>. The green/blue services can be accessed separately with these blue/green hostnames.
#: * <tt>das.example.com</tt> - This is the production host url, and is used for external access.
#: * <tt>das.blue.example.com</tt> - This is for blue service testing.
#: * <tt>das.green.example.com</tt> - This is for green service testing.
# Configure the hostnames in the '''das-values.yaml''' file under ingress, annotations, and paths (can be modified based on the requirement).
#: <source>ingress:
enabled: true
annotations: {}
paths: ["/"]
hosts:
- das.example.com
- das.blue.example.com
- das.green.example.com</source>

====Initial deployment====
The Ingress must be created initially before deploying the DAS service since it is shared between blue/green services and it is required to be created at the very beginning of the deployment. The Ingress is not required for subsequent upgrades. The required values are passed using the <code>-- set</code> flag in the following steps. Values can also be directly changed in the values.yaml file.

#Deploy initial DAS pods and other resources by choosing an active color, in this example, green. Use the below command to create a <code>designer-das-green</code> service: <code>helm upgrade --install designer-das-green -f designer-das-values.yaml designer-das-100.0.106+xxxx.tgz --set das.deployment.strategy=blue-green --set das.image.tag=9.0.1xx.xx.xx --set das.deployment.color=green</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>das.deployment.strategy=blue-green</code> - This denotes that the DAS service will be installed using the blue-green deployment strategy. <code>das.image.tag=9.0.1xx.xx.xx</code> - This denotes the DAS version to be installed, for example, <code>9.0.111.04.4</code>. <code>das.deployment.color=green</code> - This denotes that the green color service is installed.
#Once the initial deployment is done, the pods have to be exposed to the <nowiki><code>designer-das</code></nowiki> service. Execute the following command to create the <nowiki><code>designer-das</code></nowiki> service: <code>helm upgrade --install designer-das designer-das-100.0.106+xxx.tgz -f designer-das-values.yaml --set das.deployment.strategy=blue-green-service --set das.deployment.color=green</code> The values.yaml overrides passed as an argument to the above helm upgrade <code>das.deployment.strategy=blue-green-service</code> - This denotes that the designer-das service will be installed and exposed to the active color pods. <code>das.deployment.color=green</code> - This denotes that the designer-das service will point to green pods.
# Create ingress rules for the DAS service (assuming the ingress service is <tt>das-ingress</tt>):
<source language=text>helm upgrade --install das-ingress designer-das-100.0.106+xxxx.tgz -f designer-das-values.yaml --set das.deployment.strategy=blue-green-ingress</source>
The values.yaml overrides passed as an argument to the above command 
<tt>das.deployment.strategy=blue-green-ingress</tt> - This denotes that the helm install will create ingress rules for the DAS service.

{{NoteFormat|Step 3 is required only when ingress is to be created to expose DAS outside the cluster.}}

'''NodePort Service'''

The <code>designer-das-green</code> release creates a service called <code>designer-das-green</code> and the <code>designer-das-blue</code> release creates a service called <code>designer-das-blue</code>. If you are using NodePort services, ensure that the value of <code>designer.service.nodePort</code> is not the same for both the releases. In other words, you should assign dedicated node ports for the releases. The default value for <code>designer.service.nodePort</code> is '''30280'''. If this was applied to <code>designer-das-green</code>, use a different value for <code>designer-das-blue</code>, for example, '''30281'''. Use the below helm command to achieve this:
<code>helm upgrade --install designer-das designer-das-100.0.106+xxx.tgz -f designer-das-values.yaml --set das.deployment.strategy=blue-green-service --set das.deployment.color=green --set das.service.nodePort=30281</code>
===8.9 Canary===
Canary is optional and is only used along with Blue-Green. It is recommended in production. Canary pods are generally used to test new versions of images with live traffic. If you are not opting for Canary, skip the steps in this section.

'''Canary deployment'''

#Identify the current production color by checking the <code>designer-das</code> service selector labels (<code>kubectl describe service designer-das</code>). Green is the production color in the below example as the selector label is <code>color=green</code>. [[File:CanaryInDepStep1.png|border]]
#To deploy canary pods, the <code>das.deployment.strategy</code> value must be set to <code>canary</code> in the '''designer-das-values.yaml''' file or using the <code>-- set</code> flag as shown in the command below: <code>helm upgrade --install designer-das-canary -f das-values.yaml designer-das-100.0.106+xxxx.tgz --set das.deployment.strategy=canary --set das.image.tag=9.0.1xx.xx.xx --set das.deployment.color=green</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>das.deployment.strategy=canary</code> - This denotes that the Helm install will create canary pods. <code>das.deployment.color=green</code> - This denotes that the current production (active) color is green.{{NoteFormat|1=To make sure Canary pods receive live traffic, they have to be exposed to the <code>designer-das</code> service by setting <code>das.deployment.color=<active_color></code>, which is obtained from step 1.|2=}}
#Once canary pods are up and running, ensure that the designer-das service points to the canary pods using the <code>kubectl describe svc designer-das</code> command. [[File:CanaryEndpoints.png|border]] The IP address present in the Endpoints must match the IP address of the canary pod. The canary pod's IP address is obtained using the <code>kubectl describe pod <canary_pod_name></code> command. [[File:CanaryIPs.png|border]]

'''Cleaning up'''

After completing canary testing, the canary pods must be cleaned up.

The <code>das.deployment.replicaCount</code> must be made zero and the release is upgraded. It can be changed in the '''designer-das-values.yaml''' file or through the <code>--set</code> flag as follows:

*<code>helm upgrade --install designer-das-canary -f das-values.yaml designer-das-100.0.106+xxxx.tgz --set das.deployment.strategy=canary --set das.image.tag=9.0.1xx.xx.xx --set das.deployment.color=blue --set das.deployment.replicaCount=0</code>
{{AnchorDiv|dasupgrade}}
====Upgrade====

#Identify the current production color by checking the <code>designer-das</code> service selector labels (<code>kubectl describe service designer-das</code>). Green is the production color in the below example as the selector label is <code>color=green</code>. [[File:DasBGUpgStep1.png|border]]
#Deploy the DAS service on to the non-production color. For the above example, blue is the non-production color and assuming the service name is <code>designer-das-blue</code>): <code>helm upgrade --install designer-das-blue -f das-values.yaml designer-das-100.0.106+xxxx.tgz --set das.deployment.strategy=blue-green --set das.image.tag=9.0.1xx.xx.xx --set das.deployment.color=blue</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>das.deployment.strategy=blue-green</code> - This denotes that the DAS service is installed using the blue-green strategy. <code>das.image.tag=9.0.1xx.xx.xx</code> - This denotes the new DAS version to be installed, for example, <code>9.0.111.05.5</code>. <code>das.deployment.color=blue</code> - This denotes that the blue color service is installed. The non-production color can be accessed with the non-production service name.
{{AnchorDiv|dascutover}}
====Cutover====
Once testing is completed on the non-production color, traffic can be moved to the new version by updating the <code>designer-das</code> service.

#Update the <code>designer-das</code> service with the new deployment color by executing the below command. In this example, blue is the new deployment color (non-production color). <code>helm upgrade --install designer-das-service -f designer-das-values.yaml designer-das-100.0.106+xxxx.tgz --set das.deployment.strategy=blue-green-service --set das.deployment.color=blue</code>
#Verify the service by executing the <code>kubectl describe service designer-das</code> command. The type label must have the active color's label, that is, <code>color=blue</code>.

====Rollback====

#If the upgrade must be rolled back, cutover has to performed again to make the service point to the old deployment (green) again. Use the below command to perform the cutover: <code>helm upgrade --install designer-das-service -f designer-das-values.yaml designer-das-100.0.106+xxxx.tgz --set das.deployment.strategy=blue-green-service --set das.deployment.color=green</code> The values.yaml overrides passed as an argument to the above Helm upgrade command: <code>das.deployment.strategy=blue-green-service</code> - This denotes that the Helm install will create ingress rules for the DAS service. <code>das.deployment.color=green</code> - This denotes that the current production (active) color is green.
#Verify the service by executing the <code>kubectl describe service designer-das</code> the command. The type label must have the active color's label, that is, <code>color=green</code>.

===8.10 Validations and checks===

Here are some common validations and checks that can be performed to know if the deployment was successful.

*Check if the application pods are in running state by using the <code>kubectl get pods</code> command.

*Try to connect to the Designer or DAS URL as per the ingress rules from your browser. You must be able to access the Designer and DAS webpages.

 
|Status=No
}}{{Section
|sectionHeading=9. Post deployment procedures
|anchor=postdeppros
|alignment=Vertical
|structuredtext====Upgrading the Designer workspace===
Workspace resources must be upgraded after cutover. This will upgrade the system resources in the Designer workspace:

#Login to one of the Designer pods using the <code>kubectl exec -it <pod_name ></code> bash command.
#Execute the following migration command (this will create new directories/new files introduced in the new version): <code>node ./bin/cli.js workspace-upgrade -m -t <contact_center_id></code>
#Execute the workspace resource upgrade command (this will upgrade system resources, such as system service PHP files, internal audio files and callback resources): <code>node ./bin/cli.js workspace-upgrade -t <contact_center_id></code> In the above command, <code>contact_center_id</code> , is the Contact Center ID created in GWS for this tenant (workspace resources are located under the Contact Center ID folder (''/workspaces/<ccid>/workspace'')).
{{NoteFormat|The above steps will also be used for further upgrades.|}}

{{AnchorDiv|updateflowset}}
===Updating the flowsettings file===
Post deployment, the '''flowsettings.json''' file can be modified through a Helm install as follows:

#Extract the Designer Helm Chart and find the '''flowsettings.yaml''' file under the ''Designer Chart > Config'' folder.
#Modify the necessary settings (refer to the ''Post deployment configuration settings reference table'' for the different settings and their allowed values).
#Execute the below Helm upgrade command on the non-production color service. It can be done as part of the Designer upgrade by passing the '''flowsettings.yaml''' file using the <code>--values</code> flag. In this case, a new Designer version can be used for the upgrade. If it is only a '''flowsettings.json''' update, the same Designer version is used. <code>helm upgrade --install designer-blue -f designer-values.yaml -f flowsettings.yaml designer-9.0.xx.tgz --set designer.deployment.strategy=blue-green --set designer.image.tag=9.0.1xx.xx.xx --set designer.deployment.color=blue</code>
#Once testing is completed on the non-production service, perform the cutover step as mentioned in the Cutover section (Designer Blue-Green deployment). After cutover, the production service will contain the updated settings. The non-active color Designer must also be updated with the updated settings after the cutover. 
|Status=No
}}
{{Section
|sectionHeading=10. Enabling optional features
|anchor=enopfts
|alignment=Vertical
|structuredtext====10.1 Enable Designer Analytics and Audit Trail===
Post Designer deployment, features such as Analytics and Audit Trail can be enabled by performing the below steps.
{{NoteFormat|Ensure Elasticsearch is deployed before proceeding.}}

====10.1.1 Designer changes====

#Configure the following settings in flowsettings override ('''flowsettings.yaml''') - Refer to the ''5.4 Post deployment configuration settings reference table'' section for option descriptions.
#*enableAnalytics: true
#*enableESAuditLogs: true
#*esServer
#*esPort
#*esUrl
#Configure the below setting in the DesignerEnv transaction list: <code>ReportingURL</code> in the '''reporting''' section.
#Perform the steps in the ''Updating the flowsettings file'' section under ''9. Post deployment procedures''.

====10.1.2 DAS changes====

#Configure the following settings in the helm '''das-values.yaml''' file. Refer to the ''4.2 DAS deployment settings'' section for setting descriptions. <code>dasEnv.envs.DAS_SERVICES_ELASTICSEARCH_ENABLED = true</code> <code>dasEnv.envs.DAS_SERVICES_ELASTICSEARCH_HOST</code> <code>dasEnv.envs.DAS_SERVICES_ELASTICSEARCH_PORT</code>
#Perform the steps in the ''Upgrade non production color'' section (see ''DAS'' under ''8.8 Blue-Green deployment''). The same DAS version running in production can be used for the upgrade.
#Perform the steps in the ''Cutover'' section (see ''DAS'' under ''8.8 Blue-Green deployment'').

===10.2 Enable Personas===
You can enable the Personas feature in Designer by following the below steps.
====10.2.1 Deploy personas.json====

*Deploy the '''personas.json''' file in the workspace location, <code>/workspace/{tenantID}/workspace/personas/personas.json.</code>
*Create the '''personas''' directory if it does not exist.

Given below is a sample '''personas.json''' file:<source>[
{
"id": "1",
"name": "Samantha",
"gender": "female",
"tags": ["female", "middle-age", "default"],
"displayPersona": "female, 30-40s, professional, calm",
"voice": [{
"name": "samantha",
"language": "en-US",
"ttsname": "Samantha",
"ttsengine": "NuanceTTS",
"displayName": "Samantha"
}, {
"name": "karen",
"language": "en-AU",
"ttsname": "Karen",
"ttsengine": "NuanceTTS",
"displayName": "Karen"
}, {
"name": "amelie",
"language": "fr-CA",
"ttsname": "Amelie",
"ttsengine": "NuanceTTS",
"displayName": "Amelie"
}, {
"name": "paulina",
"language": "es-MX",
"ttsname": "Paulina",
"ttsengine": "NuanceTTS",
"displayName": "Paulina"
}
],
"digital": {},
"email": {},
"chat": {},
"web": {}
},
{
"id": "2",
"name": "Tom",
"gender": "male",
"tags": ["male", "middle-age"],
"displayPersona": "male, 30-40s, polite, professional",
"voice": [{
"name": "tom",
"language": "en-US",
"ttsname": "Tom",
"ttsengine": "NuanceTTS",
"displayName": "Tom"
}, {
"name": "lee",
"language": "en-AU",
"ttsname": "Lee",
"ttsengine": "NuanceTTS",
"displayName": "Lee"
}, {
"name": "felix",
"language": "fr-CA",
"ttsname": "Felix",
"ttsengine": "NuanceTTS",
"displayName": "Felix"
}, {
"name": "javier",
"language": "es-MX",
"ttsname": "Javier",
"ttsengine": "NuanceTTS",
"displayName": "Javier"
}
],
"digital": {},
"email": {},
"chat": {},
"web": {}
},
{
"id": "3",
"name": "Gabriela",
"gender": "female",
"tags": ["female", "young", "engaging"],
"displayPersona": "female, 20-30s, engaging",
"voice": [{
"name": "gabriela",
"language": "en-US",
"ttsname": "en-US-Standard-E",
"ttsengine": "GTTS",
"displayName": "Gabriela"
}, {
"name": "sheila",
"language": "en-AU",
"ttsname": "en-AU-Standard-A",
"ttsengine": "GTTS",
"displayName": "Sheila"
}, {
"name": "lili",
"language": "fr-CA",
"ttsname": "fr-CA-Standard-A",
"ttsengine": "GTTS",
"displayName": "Lili"
}
],
"digital": {},
"email": {},
"chat": {},
"web": {}
},
{
"id": "4",
"name": "Michael",
"gender": "male",
"tags": ["male", "young"],
"displayPersona": "male, 20-30s, curious, geeky",
"voice": [{
"name": "michael",
"language": "en-US",
"ttsname": "en-US-Standard-B",
"ttsengine": "GTTS",
"displayName": "Michael"
}, {
"name": "royce",
"language": "en-AU",
"ttsname": "en-AU-Standard-B",
"ttsengine": "GTTS",
"displayName": "Royce"
}, {
"name": "alexandre",
"language": "fr-CA",
"ttsname": "fr-CA-Standard-B",
"ttsengine": "GTTS",
"displayName": "Alexandre"
}
],
"digital": {},
"email": {},
"chat": {},
"web": {}
},
{
"id": "5",
"name": "Diane",
"gender": "female",
"tags": ["female", "mature"],
"displayPersona": "female, 40-50s, soothing, silky",
"voice": [{
"name": "diane",
"language": "en-US",
"ttsname": "en-US-Standard-C",
"ttsengine": "GTTS",
"displayName": "Diane"
}, {
"name": "muriel",
"language": "en-AU",
"ttsname": "en-AU-Standard-C",
"ttsengine": "GTTS",
"displayName": "Muriel"
}, {
"name": "chloe",
"language": "fr-CA",
"ttsname": "fr-CA-Standard-C",
"ttsengine": "GTTS",
"displayName": "Chloe"
}
],
"digital": {},
"email": {},
"chat": {},
"web": {}
},
{
"id": "6",
"name": "David",
"gender": "male",
"tags": ["male", "mature"],
"displayPersona": "male, 40-50s, professional, confident",
"voice": [{
"name": "david",
"language": "en-US",
"ttsname": "en-US-Standard-D",
"ttsengine": "GTTS",
"displayName": "David"
}, {
"name": "austin",
"language": "en-AU",
"ttsname": "en-AU-Standard-D",
"ttsengine": "GTTS",
"displayName": "Austin"
}, {
"name": "pierre",
"language": "fr-CA",
"ttsname": "fr-CA-Standard-D",
"ttsengine": "GTTS",
"displayName": "Pierre"
}
],
"digital": {},
"email": {},
"chat": {},
"web": {}
}
]</source>
====10.2.2 Update Designer flowsettings.json====

*Enable the persona <code>feature</code> flag in the '''flowsettings.json''' override file.
<source>"features": {
"persona": true</source>
===Update application settings===
Perform the following steps to enable the persona in the required Designer application:

#Open the required Designer application and navigate to the '''Settings''' tab.
#In '''Application Settings''', select the '''Enable''' '''Persona''' checkbox in the '''Persona''' tab.
#Re-publish the application and create a new build.
|Status=No
}}
{{Section
|sectionHeading=11. Cleanup
|anchor=cleanup
|alignment=Vertical
|structuredtext====11.1 Elasticsearch maintenance recommendations===
To help you better manage your indexes and snapshots, and to prevent too many indexes from creating an overflow of shards, Genesys recommends that you set up a scheduled execution of Elasticsearch Curator with the following two actions:

*Delete indexes older than the given threshold according to the index name and mask.
**<code>sdr-*</code> (3 months)
**<code>audit-*</code> (12 months)

*Make a snapshot of each index:
**<code>sdr-*</code> (yesterday and older)
**<code>audit-*</code>
**<code>kibana-int-*</code>
|Status=No
}}{{Section
|sectionHeading=12. Limitations
|anchor=limits
|alignment=Vertical
|structuredtext=Designer currently supports multi-tenancy provided by the tenant Configuration Server. That is, each tenant should have a dedicated Configuration Server, and Designer can be shared across the multiple tenants.
|Status=No
}}
}}

DES/Current/Deployment/DeployDesigner

2022-03-24T19:30:39Z

MPandian: Published

{{Article
|Standalone=No
|DisplayName=Deploy Designer (versions v9010005 and above)
|TocName=Deploy Designer (versions v9010005 and above)
|Context=Learn how to deploy Designer as a service in a Kubernetes cluster (for '''DesDepMnfst v9010005''' and above).
|ComingSoon=No
|Platform=GenesysEngage-onpremises
|Section={{Section
|sectionHeading=1. About this document
|anchor=abtdoc
|alignment=Vertical
|structuredtext=This document guides you through the process of deploying and configuring Designer and Designer Application Server (DAS) as a service in a Kubernetes (K8s) cluster.

Information on the following topics is provided:

*Overview of Designer and DAS
*Configuration details
*Deployment process
*Enabling optional features
*Cleanup
*Known limitations

===1.1 Intended audience===
This document is intended for use primarily by system engineers and other members of an implementation team who will be involved in configuring and installing Designer and DAS, and system administrators who will maintain Designer and DAS installations.

To successfully deploy and implement applications in Designer and DAS, you must have a basic understanding of and familiarity with:

*Network design and operation
*Network configurations in your organization
*Kubernetes
*Genesys Framework architecture and functions

===1.2 Before you begin===

#A Kubernetes cluster must be deployed. Refer to the [https://kubernetes.io/docs/home/ Kubernetes documentation site] for installation instructions.
#Install Helm according to the instructions outlined in the [https://helm.sh/docs/using_helm/ Helm documentation site].

After you complete the above mandatory procedures, return to this document to complete an on-premise deployment of Designer and DAS as a service in a K8s cluster.
 
|Status=No
}}{{Section
|sectionHeading=2. Product overview
|anchor=prodoverview
|alignment=Vertical
|structuredtext=The following sections provide a brief overview of Designer and DAS.

===2.1 Designer===
The Designer service provides a web UI to build and manage VXML and SCXML based self-service and assisted service applications for a number of media types. It stores data on the local file system and is synchronized across instances by using services like Network File System (NFS). Genesys customers can build applications using a simple drag and drop method, and assign contact points (Route Points and other media endpoints) to applications directly from the Designer UI. Insights into runtime behavior of applications and troubleshooting aid is provided by Designer Analytics, which includes a rich set of dashboards based on session detail records (SDR) from data stored in Elasticsearch.

Designer offers the following features:

*Applications for working with phone, chat, email, SMS (text messages), Facebook, Twitter, and open media types.
*Bots, ASR, TTS capabilities for self-service.
*Assisted service or routing.
*Callback.
*Business Controls.
*Audio, message management.
*Grammars management.
*Contact points management - route points, chat end points, email pop-client/mailboxes.
*Analytics dashboards through embedded Kibana.

Designer is an Express/Node.js application. The UI is designed using Angular powered Bootstrap. Application data (SCXML and VXML) is stored as a file system. Designer Analytics and Audit data is stored in Elasticsearch.

===2.2 Designer Application Server (DAS)===
Designer Application Server (DAS) hosts and serves the Designer generated application files (SCXML and VXML), audio, and grammars. It also provides:

*Runtime evaluation of Business Controls (business hours, special days, emergency flags and data tables).
*Callback interface to GES.
*Interface to External APIs.

DAS uses built-in NGINX to front requests. It consists of 3 modules: NGINX, PHP, and Node.js.

*Requests for static workspace content (SCXML, VXML, JS, audio, grammar, etc) are handled by the NGINX module.
*Requests for PHP content are processed by the FastCGI PHP module.
*SDR (Analytics) processing requests are handled by the DAS Node.js module.

{{NoteFormat|Files generated by Designer can be served only by DAS. Designer will work only with DAS.|}}

===2.3 Deployment architecture===
The below architecture diagram illustrates a sample premise deployment of Designer and DAS:

[[File:Premise-Designer-DAS-architecture.png]]

===2.4 High Availability (HA) and Scalability===
Designer and DAS must be deployed as highly available in order to avoid single points of failure. A minimum of 2 replicas of each service must be deployed to achieve HA.

The Designer and DAS service pods can be automatically scaled up or down based on metrics such as CPU and memory utilization. The ''Deployment configuration settings'' section explains how to configure HA and auto-scaling.

Refer to the [https://docs.genesys.com/Documentation/System/8.5.x/DDG/HAandDRNotes Genesys Docker Deployment Guide] for more information on general HA recommendation for Kubernetes.
 
|Status=No
}}{{Section
|sectionHeading=3. Prerequisites
|anchor=prereqs
|alignment=Vertical
|structuredtext=Before deploying Designer, ensure the following resources are deployed, configured, and accessible:

===3.1 Mandatory prerequisites===

*Kubernetes 1.12+
*Helm 3.0
*Docker Registry
**Setup a local docker registry to store Designer and DAS docker images.
*Ingress Controller
**If Designer and DAS are accessed from outside of a K8s cluster, it is recommended to deploy/configure an ingress controller (for example, NGINX), if not already available. Also, the Blue-Green deployment strategy works based on the ingress rules.
**The Designer UI requires ''Session Stickiness''. Configure session stickiness in the ''annotations'' parameter in the '''values.yaml''' file during Designer installation.
*Persistent Volumes (PVs)
**Create persistent volumes for workspace storage (5 GB minimum) and logs (5 GB minimum)
**Set the access mode for these volumes to ''ReadWriteMany''.
**The Designer manifest package includes a sample YAML file to create Persistent Volumes required for Designer and DAS.
**Persistent volumes must be shared across multiple K8s nodes. Genesys recommends using NFS to create Persistent Volumes.
*Shared file System - NFS
**For production, deploy the NFS server as highly available (HA) to avoid single points of failure. It is also recommended that the NFS storage be deployed as a Disaster Recovery (DR) topology to achieve continuous availability if one region fails.
**By Default, Designer and DAS containers run as a Genesys user (<code>uid:gid 500:500</code>). For this reason, the shared volume must have permissions that will allow write access to <code>uid:gid 500:500</code>. The optimal method is to change the NFS server host path to the Genesys user: <code>chown -R genesys:genesys</code>.
**The Designer manifest package includes a sample YAML file to create an NFS server. Use this only for a demo/lab setup purpose.
*Genesys Web Services (GWS) 9.x
**Configure GWS to work with a compatible version of Configuration Server.
*Other Genesys Components
**ORS ORS 8.1.400.x
**Nexus 9.x
**URS 8.1.400.x

===3.2 Optional prerequisites===

*Elasticsearch 7.8.0
**Elasticsearch is used for Designer Analytics and audit trail.
*Redis 3.2.x
**Redis is used for resource index caching and multi-user collaboration locks on Designer resources.
|Status=No
}}{{Section
|sectionHeading=4. Deployment configuration settings (Helm values)
|anchor=depconfigset
|alignment=Vertical
|structuredtext=This section provides information on the various settings that have to be configured in Designer and DAS. The configuration settings listed below will be used during the deployment of Designer and DAS. That is, these settings will be used during initial deployment / upgrade. These settings can be configured in the '''values.yaml''' Helm file.

===4.1 Designer deployment settings===
The following table provides information on the Designer deployment settings. These settings are configured in the '''designer-values.yaml''' file.
{{{!}} class="wikitable"
{{!}}Parameter
{{!}}Description
{{!}}Mandatory?
{{!}}Default Value
{{!}}-
{{!}}<code>deployment.replicaCount</code>
{{!}}Number of services to be created.
{{!}}Mandatory
{{!}}2
{{!}}-
{{!}}<code>deployment.maxReplicas</code>
{{!}}Maximum number of replicas created. It is recommended to configure this setting if auto-scaling is used.
{{!}}Optional
{{!}}10
{{!}}-
{{!}}<code>deployment.strategy</code>
{{!}}The strategy to select which type of resources to deploy. Valid values are: <code>default, service, volume, ingress</code>.

*'''volume''' - for blue/green upgrade, this is to create a Persistent Volume Claim (PVC) for the first time.
*'''ingress''' - for the blue/green upgrade, this is to create an ingress for the first time and update the ingress during service cutover.
*'''service''' - for upgrading the blue/green Designer service.
*'''default''' - for performing a rolling upgrade
{{!}}Mandatory
{{!}}service
{{!}}-
{{!}}<code>deployment.green</code>
{{!}}This is to deploy/upgrade the Designer service in a blue-green upgrade strategy. Valid values are: <code>blue, green</code>.
{{!}}Optional
{{!}}green
{{!}}-
{{!}}<code>desImage.repository</code>
{{!}}Docker repository for the Designer image.
{{!}}Mandatory
{{!}}[http://pureengage-docker-staging.jfrog.io/designer/designer pureengage-docker-staging.jfrog.io/designer/designer]
{{!}}-
{{!}}<code>desImage.tag</code>
{{!}}Designer image version.
{{!}}Mandatory
{{!}}9.0.109.08.20
{{!}}-
{{!}}<code>desImage.pullPolicy</code>
{{!}}Designer image pull policy (imagePullPolicy). Valid values: <code>Always, IfNotPresent, Never</code>.

*'''Always''' - always pull the image.
*'''IfNotPresent''' - pull the image only if it does not already exist on the node.
*'''Never''' - never pull the image.
{{!}}Mandatory
{{!}}IfNotPresent
{{!}}-
{{!}}<code>volumes.workspaceMountPath</code>
{{!}}The path where the workspace volume is to be mounted inside the Designer container.
{{!}}Mandatory
{{!}}/designer/workspace
(Changing this value is not recommended.)
{{!}}-
{{!}}<code>volumes.workspaceClaim</code>
{{!}}Persistent volume claim name for the workspace.
{{!}}Mandatory
{{!}}designer-managed-disk
{{!}}-
{{!}}<code>volumes.workspaceClaimSize</code>
{{!}}Size of the persistent volume claim for the workspace.
The persistent volume must be equal to or greater than this size.
{{!}}Mandatory
{{!}}5Gi
{{!}}-
{{!}}<code>volumes.workspaceStorageClass</code>
{{!}}storageClassName provided in the persistent volume that is created for the Designer workspace (example, ''nfs'').
{{!}}Mandatory
{{!}}manual
{{!}}-
{{!}}<code>volumes.logMountPath</code>
{{!}}The path where the Designer logs volume is to be mounted inside the Designer container.
{{!}}Mandatory
{{!}}/designer/logs
{{!}}-
{{!}}<code>volumes.logClaim</code>
{{!}}Persistent volume claim name for logs.
{{!}}Mandatory
{{!}}designer-logs
{{!}}-
{{!}}<code>volumes.logClaimSize</code>
{{!}}Size of the persistent volume claim for the Designer logs.
The persistent volume must be equal to or greater than this size.
{{!}}Mandatory
{{!}}5Gi
{{!}}-
{{!}}<code>volumes.logStorageClass</code>
{{!}}storageClassName provided in the persistent volume that is created for the Designer logs (example, nfs).
{{!}}Mandatory
{{!}}manual
{{!}}-
{{!}}<code>healthApi.path</code>
{{!}}Designer Health Check API path.
{{!}}Mandatory
{{!}}/health
(Changing this value is not recommended.)
{{!}}-
{{!}}<code>healthApi.containerPort</code>
{{!}}Container running port.
{{!}}Mandatory
{{!}}8888
(Changing this value is not recommended.)
{{!}}-
{{!}}<code>healthApi.startupDelay</code>
{{!}}Health check will be started after a delay as specified in this setting.
{{!}}Mandatory
{{!}}20
{{!}}-
{{!}}<code>healthApi.checkInterval</code>
{{!}}The interval between each health check request.
{{!}}Mandatory
{{!}}5
{{!}}-
{{!}}<code>healthApi.failureCount</code>
{{!}}Number of health check failures to be considered before marking the container as instable or restart.
{{!}}Mandatory
{{!}}5
{{!}}-
{{!}}<code>designerEnv.enabled</code>
{{!}}This enables providing environment variables as an input to Designer pods.
It uses <code>ConfigMap</code> to store the environment variables.
{{!}}Mandatory
{{!}}true
(Changing this value is not recommended.)
{{!}}-
{{!}}<code>designerEnv.envs.DES_PORT</code>
{{!}}Designer port for container (<code>port</code> in flowsettings.json).
{{!}}Mandatory
{{!}}8888
{{!}}-
{{!}}<code>designerEnv.envs.DES_APPSERVER_HOST</code>
{{!}}DAS hostname (<code>applicationHost</code> in flowsettings.json).
{{!}}Mandatory
{{!}}das
{{!}}-
{{!}}<code>designerEnv.envs.DES_APPSERVER_PORT</code>
{{!}}DAS port (<code>applicationPort</code> in flowsettings.json).
{{!}}Mandatory
{{!}}80
{{!}}-
{{!}}<code>designerEnv.envs.DES_DEPLOY_URL</code>
{{!}}This is normally not changed. It is the relative path to the workspace on DAS.
The default value <code>/workspaces</code> should be always be used (<code>deployURL</code> in flowsettings.json).
{{!}}Mandatory
{{!}}/workspaces
{{!}}-
{{!}}<code>designerEnv.envs.DES_USE_HTCC</code>
{{!}}Set to <code>true</code> so Designer works with GWS. If set to <code>false</code>. Designer defaults to a local mode and may be used temporarily if GWS is unavailable (<code>usehtcc</code> in flowsettings.json).
{{!}}Mandatory
{{!}}true
(Changing this value is not recommended.)
{{!}}-
{{!}}<code>designerEnv.envs.DES_HTCC_SERVER</code>
{{!}}GWS server host (<code>htccserver</code> in flowsettings.json), for example, <code>gws.genhtcc.com</code>.
{{!}}Mandatory
{{!}}[http://gws-usw1-int.genhtcc.com/ gws-usw1-int.genhtcc.com]
{{!}}-
{{!}}<code>designerEnv.envs.DES_HTCC_PORT</code>
{{!}}GWS server port (<code>htccport</code> in flowsettings.json), for example, 80.
{{!}}Mandatory
{{!}}80
{{!}}-
{{!}}<code>designerEnv.envs.DES_ENABLE_ANALYTICS</code>
{{!}}To enable or disable Designer Analytics (<code>enableAnalytics</code> in flowsettings.json).
{{!}}Optional
{{!}}false
{{!}}-
{{!}}<code>designerEnv.envs.DES_ES_URL</code>
{{!}}Elasticsearch URL (for example, [http://designer-es-client-service:9200/ http://es-service:9200]), <code>esUrl</code> in flowsettings.json.
{{!}}Optional
{{!}}[http://es-spot.usw1.genhtcc.com/ http://es-spot.usw1.genhtcc.com]
{{!}}-
{{!}}<code>designerEnv.envs.DES_ES_SERVER</code>
{{!}}Elasticsearch Server HostName (for example, es-service), <code>esServer</code> in flowsettings.json.
{{!}}Optional
{{!}}[http://es-spot.usw1.genhtcc.com/ es-spot.usw1.genhtcc.com]
{{!}}-
{{!}}<code>designerEnv.envs.DES_ES_PORT</code>
{{!}}Elasticsearch port (for example, 9200), <code>esPort</code> in flowsettings.json.
{{!}}Optional
{{!}}80
{{!}}-
{{!}}<code>designerEnv.envs.DES_FILE_LOGGING_ENABLED</code>
{{!}}Enable file logging. If not enabled, Designer will output only verbose logs.
{{!}}Mandatory
{{!}}false
{{!}}-
{{!}}<code>designerSecrets.enabled</code>
{{!}}This enables providing the GWS client ID / secret as an input to Designer pods.
It uses Kubernetes Secrets to store the GWS client credentials.
{{!}}
{{!}}true
{{!}}-
{{!}}<code>designerSecrets</code>.GWS_Client_id
{{!}}GWS Client ID, create a new GWS client if it doesn't exist, steps are explained in the platform settings section.
{{!}}Mandatory
{{!}}designer-secret
{{!}}-
{{!}}<code>designerSecrets</code>.GWS_Client_secret
{{!}}GWS Client secret
{{!}}Mandatory
{{!}}ZXh0ZXJuYWxfYXBpX2NsaWVudA==
(This value is valid only for lab deployments.)
{{!}}-
{{!}}<code>service.type</code>
{{!}}Service type (either <code>ClusterIP</code> or <code>NodePort</code> or <code>LoadBalancer</code>).
{{!}}Mandatory
{{!}}ClusterIP
{{!}}-
{{!}}<code>service.port</code>
{{!}}Designer service port to be exposed in the cluster.
{{!}}Mandatory
{{!}}8888
{{!}}-
{{!}}<code>service.targetPort</code>
{{!}}Designer application port running inside the container.
{{!}}Mandatory
{{!}}8888
{{!}}-
{{!}}<code>service.nodePort</code>
{{!}}Port to be exposed in case <code>service.type=NodePort</code>.
{{!}}Optional
{{!}}Sample value : 30180
{{!}}-
{{!}}<code>ingress.enabled</code>
{{!}}Enable/Disable ingress. Ingress should be enabled for all cases except a lab/demo setup.
{{!}}Mandatory
{{!}}true
{{!}}-
{{!}}<code>ingress.paths</code>
{{!}}Ingress path
{{!}}Mandatory
{{!}}[/]
{{!}}-
{{!}}<code>ingress.hosts</code>
{{!}}Hostnames to be configured in ingress for the Designer service.
{{!}}Mandatory
{{!}}[http://ssdev1.genhtcc.com/ ssdev1.genhtcc.com]
{{!}}-
{{!}}<code>ingress.tls</code>
{{!}}TLS config for ingress.
{{!}}Optional
{{!}}[]
{{!}}-
{{!}}<code>resources.limits.cpu</code>
{{!}}Maximum amount of CPU processing power that K8s allocates for the container.
{{!}}Mandatory
{{!}}600m
{{!}}-
{{!}}<code>resources.limits.memory</code>
{{!}}Maximum amount of memory K8s allocates for the container.
{{!}}Mandatory
{{!}}1Gi
{{!}}-
{{!}}<code>resources.requests.cpu</code>
{{!}}Guaranteed CPU allocation for the container.
{{!}}Mandatory
{{!}}500m
{{!}}-
{{!}}<code>resources.requests.memory</code>
{{!}}Guaranteed memory allocation for the container.
{{!}}Mandatory
{{!}}512Mi
{{!}}-
{{!}}<code>securityContext.runAsUser</code>
{{!}}Controls which user ID the containers are run with. This can be configured to run Designer as a non-root user.
Currently, only a '''Genesys''' user is supported by the Designer base image.

500 is the ID of the Genesys user and it cannot be modified.

The file system must reside within the Genesys user account in order to run Designer as a Genesys user. Change the NFS server host path to the Genesys user:

<code>chown -R genesys:genesys</code>
{{!}}Optional
{{!}}500
{{!}}-
{{!}}<code>securityContext.runAsGroup</code>
{{!}}Controls which primary group ID the containers are run with. This can be configured to run Designer as a non-root user. Currently, only a '''Genesys''' user group (GID - 500) is supported by the Designer base image.
{{!}}Optional
{{!}}500
{{!}}-
{{!}}<code>nodeSelector</code>
{{!}}To allow pods to be scheduled on the nodes based labels assigned to the nodes.
{{!}}Optional
{{!}}Default value:
<code>nodeSelector: {}</code>

Sample value:

<code>nodeSelector:</code>

<code><label_key>: <label_value></code>
{{!}}-
{{!}}<code>affinity</code>
{{!}}The K8s standard node affinity and anti-affinity configurations can be added here. Refer to this [https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/ K8s document] for sample values.
{{!}}Optional
{{!}}{}
{{!}}-
{{!}}<code>tolerations</code>
{{!}}Tolerations works with taints to ensure that pods are not scheduled onto inappropriate nodes. Refer to this [https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ K8s document] for sample values.
{{!}}Optional
{{!}}[]
{{!}}-
{{!}}<code>hpa.enabled</code>
{{!}}Enables K8s Horizontal Pod Autoscaler (HPA). It automatically scales the number of pods based on average CPU utilization and average memory utilization.
More information about HPA is available [https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/ here].
{{!}}Optional
{{!}}false
{{!}}-
{{!}}<code>hpa.targetCPUPercent</code>
{{!}}The K8s HPA controller will scale up/down pods based on the target CPU utilization percentage specified. It scales up/down pods between the range <code>deployment.replicaCount</code> to <code>deployment.maxReplicas</code>.
{{!}}Optional
{{!}}70
{{!}}-
{{!}}<code>hpa.targetMemoryPercent</code>
{{!}}The K8s HPA controller will scale up/down pods based on the target memory utilization percentage specified. It scales up/down pods between the range <code>deployment.replicaCount</code> to <code>deployment.maxReplicas</code>.
{{!}}Optional
{{!}}70
{{!}}-
{{!}}<code>annotations</code>
{{!}}Enables Kubernetes Annotations. Refer to [https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/ this] document for more information on K8s Annotations.
The Designer UI requires Session Stickiness if the replica count is more than 1. Configure session stickiness based on the ingress controller type. Ingress configuration like session stickiness can be configured here.
{{!}}Optional
{{!}}{}
{{!}}-
{{!}}<code>labels</code>
{{!}}Any custom labels can be configured. It is a key and value, for example, key:value.
{{!}}Optional
{{!}}tenant: shared
{{!}}}

===4.2 DAS deployment settings===

The following table provides information on the DAS deployment settings. These settings are configured in the '''das-values.yaml''' file.
{{{!}} class="wikitable"
{{!}}Parameter
{{!}}Description
{{!}}Mandatory?
{{!}}Default Value
{{!}}-
{{!}}<code>deployment.replicaCount</code>
{{!}}Number of services to be created.
{{!}}Mandatory
{{!}}2
{{!}}-
{{!}}<code>deployment.maxReplicas</code>
{{!}}Maximum number of replicas created. It is recommended to configure this setting if auto-scaling is used.
{{!}}Optional
{{!}}10
{{!}}-
{{!}}<code>deployment.strategy</code>
{{!}}The strategy to select which type of resources to deploy. Valid values are : <code>default, service, volume, ingress</code>.

*'''ingress''' - for the blue/green upgrade, this is to create an ingress for the first time and update the ingress during service cutover.
*'''service''' - for upgrading the blue/green DAS service.
*'''default''' - for performing a rolling upgrade.
{{!}}Mandatory
{{!}}service
{{!}}-
{{!}}<code>deployment.green</code>
{{!}}This is to deploy/upgrade the DAS service in a blue-green upgrade strategy. Valid values are: <code>blue, green</code>.
{{!}}Optional
{{!}}green
{{!}}-
{{!}}<code>dasImage.repository</code>
{{!}}Docker repository for the DAS image.
{{!}}Mandatory
{{!}}[http://pureengage-docker-staging.jfrog.io/designer/designer pureengage-docker-staging.jfrog.io/designer/das]
{{!}}-
{{!}}<code>dasImage.tag</code>
{{!}}DAS image version.
{{!}}Mandatory
{{!}}9.0.111.05.5
{{!}}-
{{!}}<code>dasVolumes.workapceMountPath</code>
{{!}}DAS workspace path inside the container.
{{!}}Mandatory
{{!}}/das/www/workspaces
{{!}}-
{{!}}<code>dasVolumes.workspaceClaim</code>
{{!}}Persistent volume claim name for the workspace (must be the same as Designer's claim name).
{{!}}Mandatory
{{!}}designer-managed-disk
{{!}}-
{{!}}<code>dasVolumes.logMountPath</code>
{{!}}DAS log path inside the container.
{{!}}Mandatory
{{!}}/das/log
{{!}}-
{{!}}<code>dasVolumes.logClaim</code>
{{!}}Persistent volume claim name for logs (must be the same as Designer's claim name).
{{!}}Mandatory
{{!}}designer-logs
{{!}}-
{{!}}<code>dasHealthApi.path</code>
{{!}}DAS Health Check API path.
{{!}}Mandatory
{{!}}/health
{{!}}-
{{!}}<code>dasHealthApi.containerPort</code>
{{!}}Container running port.
{{!}}Mandatory
{{!}}8081
{{!}}-
{{!}}<code>dasHealthApi.startupDelay</code>
{{!}}Health check will be started after a delay as specified in this setting.
{{!}}Mandatory
{{!}}10
{{!}}-
{{!}}<code>dasHealthApi.checkInterval</code>
{{!}}The interval between each health check request.
{{!}}Mandatory
{{!}}5
{{!}}-
{{!}}<code>dasHealthApi.failureCount</code>
{{!}}Number of health check failures to consider before marking the container as instable or restart.
{{!}}Mandatory
{{!}}5
{{!}}-
{{!}}<code>dasService.type</code>
{{!}}Service port (either <code>ClusterIP</code> or <code>NodePort</code> or <code>LoadBalancer</code>).
{{!}}Mandatory
{{!}}ClusterIP
{{!}}-
{{!}}<code>dasService.port</code>
{{!}}DAS service to be exposed in the cluster.
{{!}}Mandatory
{{!}}8081
{{!}}-
{{!}}<code>dasService.targetPort</code>
{{!}}DAS application port running inside the container.
{{!}}Mandatory
{{!}}8081
{{!}}-
{{!}}<code>dasService.nodePort</code>
{{!}}Port to be exposed in case <code>service.type=NodePort</code>.
{{!}}Optional
{{!}}Sample value : 30280
{{!}}-
{{!}}<code>dasEnv.enabled</code>
{{!}}This enables providing environment variables as an input to DAS pods.
It uses <code>ConfigMap</code> to store the environment variables.
{{!}}Mandatory
{{!}}true
{{!}}-
{{!}}<code>dasEnv.envs.DAS_FILE_LOGGING_ENABLED</code>
{{!}}Enable file logging. DAS supports only stdout logging, this must always be false.
{{!}}Mandatory
{{!}}false
{{!}}-
{{!}}<code>dasEnv.envs.DAS_LOG_LEVEL</code>
{{!}}Enables log levels. Valid values are: <code>FATAL, ERROR, WARN, INFO, DEBUG, TRACE</code>.
{{!}}Optional
{{!}}DEBUG
{{!}}-
{{!}}<code>dasEnv.envs.DAS_STDOUT_LOGGING_ENABLE</code>
{{!}}Enables standard output console logging.
{{!}}Mandatory
{{!}}true
{{!}}-
{{!}}<code>dasEnv.envs.DAS_SERVICES_ELASTICSEARCH_ENABLED</code>
{{!}}To enable or disable Designer Analytics. This config is required for DAS to initialize ES templates.
{{!}}Optional
{{!}}false
{{!}}-
{{!}}<code>dasEnv.envs.DAS_SERVICES_ELASTICSEARCH_HOST</code>
{{!}}Elasticsearch Server HostName with http:// prefix (for example, http://es-service)
{{!}}Optional
{{!}}[http://designer-es-client-service/ http://designer-es-client-service]
{{!}}-
{{!}}<code>dasEnv.envs.DAS_SERVICES_ELASTICSEARCH_PORT</code>
{{!}}Elasticsearch port (for example, 80)
{{!}}Optional
{{!}}9200
{{!}}-
{{!}}<code>dasresources.limits.cpu</code>
{{!}}Maximum amount of CPU processing power that K8s allocates for the container.
{{!}}Mandatory
{{!}}600m
{{!}}-
{{!}}<code>dasresources.limits.memory</code>
{{!}}Maximum amount of memory K8s allocates for the container.
{{!}}Mandatory
{{!}}1Gi
{{!}}-
{{!}}<code>dasresources.requests.cpu</code>
{{!}}Guaranteed CPU allocation for container.
{{!}}Mandatory
{{!}}400m
{{!}}-
{{!}}<code>dasresources.requests.memory</code>
{{!}}Guaranteed Memory allocation for the container.
{{!}}Mandatory
{{!}}512Mi
{{!}}-
{{!}}<code>securityContext.runAsUser</code>
{{!}}Controls which user ID the containers are run with. This can be configured to run DAS as a non-root user.
Currently, only a '''Genesys''' user is supported by the DAS base image.

500 is the ID of the Genesys user and it cannot be modified.
{{!}}Optional
{{!}}500
{{!}}-
{{!}}<code>securityContext.runAsGroup</code>
{{!}}Controls which primary group ID the containers are run with. This can be configured to run DAS as a non-root user. Currently, only a '''Genesys''' user group (GID - 500) is supported by the DAS base image.
{{!}}Optional
{{!}}500
{{!}}-
{{!}}nodeSelector
{{!}}To allow pods to be scheduled on the nodes-based labels assigned to the nodes.
{{!}}Optional
{{!}}Default value:
<code>nodeSelector: {}</code>

Sample value:

<code>nodeSelector:</code>

<code><label_key>: <label_value></code>
{{!}}-
{{!}}<code>affinity</code>
{{!}}The K8s standard node affinity and anti-affinity configurations can be added here. Refer to this [https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/ K8s document] for sample values.
{{!}}Optional
{{!}}{}
{{!}}-
{{!}}<code>tolerations</code>
{{!}}Tolerations works with taints to ensure that pods are not scheduled onto inappropriate nodes. Refer to this [https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ K8s document] for sample values.
{{!}}Optional
{{!}}[]
{{!}}-
{{!}}<code>hpa.enabled</code>
{{!}}Enables K8s Horizontal Pod Autoscaler (HPA). It automatically scales the number of pods based on average CPU utilization and average memory utilization.
More information about HPA is available [https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/ here].
{{!}}Optional
{{!}}false
{{!}}-
{{!}}<code>hpa.targetCPUPercent</code>
{{!}}The K8s HPA controller will scale up/down pods based on the target CPU utilization percentage specified. It scales up/down pods between the range <code>deployment.replicaCount</code> to <code>deployment.maxReplicas</code>.
{{!}}Optional
{{!}}75
{{!}}-
{{!}}<code>hpa.targetMemoryPercent</code>
{{!}}The K8s HPA controller will scale up/down pods based on the target memory utilization percentage specified. It scales up/down pods between the range <code>deployment.replicaCount</code> to <code>deployment.maxReplicas</code>.
{{!}}Optional
{{!}}70
{{!}}-
{{!}}<code>annotations</code>
{{!}}Enables Kubernetes Annotations. Refer to [https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/ this] document for more information on K8s Annotations.
{{!}}Optional
{{!}}{}
{{!}}-
{{!}}<code>labels</code>
{{!}}Any custom labels can be configured. It is a key and value, for example, key:value.
{{!}}Optional
{{!}}tenant: shared
{{!}}}
|Status=No
}}{{Section
|sectionHeading=5. Post deployment Designer settings
|anchor=postdepset
|alignment=Vertical
|structuredtext=Post deployment, Designer configuration is managed from the following 3 locations:

===5.1 Flow settings===
Flow Settings is used for controlling global Designer settings that are applicable to all tenants and it contains bootstrap configuration settings such as port, GWS info, and DAS URL.

Configuration path - <code>/workspace/designer/flowsettings.json</code>.

This will be configured using the helm install. The ''Flowsettings.json update'' section (''8.2.2 Designer deployment process'') describes the steps to update the '''flowsettings.json''' file.

===5.2 Tenant settings===
These are tenant specific settings if the Designer service is configured with multi-tenancy .

Configuration path - <code>workspace/<contactcenter-Id>/config/tenantsettings.json</code>.

The user should logout and log back in after any changes to the '''tenantsettings.json''' file. The Designer UI will continue to show the older features until the user logs out and logs back in.

Tenant specific settings are configured by directly editing the file in the above path.

===5.3 DesignerEnv transaction list===
The DesignerEnv transaction list is available in Configuration Server (<code>Tenant/Transactions/DesignerEnv)</code>. This is mostly used to control the run-time settings. Any change to the DesignerEnv transaction list does not require the application to be published again or a new build for the application.

The user should log out and log back in for the changes to reflect in the Designer UI.

The DesignerEnv transaction list is configured using CME or GAX.

===5.4 Configuration settings reference table===
{{NoteFormat|As the following table extends beyond the margin of the page, use the horizontal scroll bar at the bottom of your browser window to view the complete table.|2}}
{{{!}} class="wikitable"
{{!}} colspan="8"{{!}}'''Category: Analytics'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}enableAnalytics (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}This flag enables or disables the analytics feature.
{{!}}true
{{!}}false
{{!}}-
{{!}}esUrl (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}Elasticsearch URL
{{!}}[http://es-spot.usw1.genhtcc.com/ http://es-spot.usw1.genhtcc.com:80]
{{!}}
{{!}}-
{{!}}esServer (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}Elasticsearch Server HostName (for example, es-service)
{{!}}[http://es-spot.usw1.genhtcc.com/ es-spot.usw1.genhtcc.com]
{{!}}
{{!}}-
{{!}}esPort (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}Elasticsearch port
{{!}}80
{{!}}
{{!}}-
{{!}}ReportingURL (optional)
{{!}}
{{!}}
{{!}}Yes
{{!}}reporting
{{!}}URL of Elasticsearch where Designer applications will report data.
{{!}}[http://es-spot.usw1.genhtcc.com/ http://es-spot.usw1.genhtcc.com:80]
{{!}}
{{!}}-
{{!}}esMaxQueryDuration (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}The maximum time range (in days) to query in Designer Analytics. Each day's data is stored in a separate index in Elasticsearch.
{{!}}90
{{!}}90
{{!}}-
{{!}}sdrMaxObjCount (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}The maximum count of nested type objects that will be captured in SDRs. When set to -1, which is the default value, no objects will be trimmed. All the ''milestones'' or ''activities'' visited in runtime are expected to be captured in an SDR.
{{!}}20
{{!}}- 1
{{!}}-
{{!}}SdrTraceLevel (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}It controls the level of SDR detail that is recorded by the <code>blocks</code> array for each application. Currently, the valid values are:

*'''100''' — Debug level and up. Currently, there are no Debug messages.
*'''200''' — Standard level and up. This setting will show all blocks that are entered during a call in the <code>blocks</code> array.
*'''300''' — Important level and up. This setting filters out all blocks from the <code>blocks</code> array, except those containing data that will change from call to call (such as the Menu block and User Input block).
{{!}}300
{{!}}300
{{!}}-
{{!}} colspan="8"{{!}}'''Category: Audit'''
{{!}}-
{{!}}Setting Name
{{!}}lowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}enableESAuditLogs (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}Enable or Disable audit logs captured in Elasticsearch.
{{!}}false
{{!}}false
{{!}}-
{{!}}enableFSAuditLogs (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}Enable or Disable audit logs captured in the file system under the '''logs''' directory or in standard output.
{{!}}true
{{!}}true
{{!}}-
{{!}}maxAppSizeCompare (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}The maximum size of data object for which a difference will be captured in the audit logs, value in bytes. That is, the difference between the Designer object's old value and new value.
{{!}}1000000
{{!}}1000000
{{!}}-
{{!}}enableReadAuditLogs (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}Control whether reading of Designer objects is captured in audit trails. If enabled any Designer object viewed in the UI will be recorded in the audit logs.
{{!}}false
{{!}}false
{{!}}-
{{!}} colspan="8"{{!}}'''Category: Authorization'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}disableRBAC (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}Controls if Designer reads and enforces permissions associated with the logged in user's roles.
{{!}}false
{{!}}false
{{!}}-
{{!}}rbacSection (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}In a Role object, the name of the section within the Annex where the privileges are stored.
{{!}}CfgGenesysAdministratorServer
{{!}}CfgGenesysAdministratorServer
{{!}}-
{{!}}disablePBAC (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}Controls if Designer allows partitioning of the Designer workspace and restricts a user's access to Designer objects in the user's partitions.
{{!}}false
{{!}}false
{{!}}-
{{!}} colspan="8"{{!}}'''Category: Collaboration'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}locking (optional)
{{!}}Yes
{{!}}
{{!}}
{{!}}
{{!}}The type of locking used, for an editing session of applications, modules, or data tables.

Valid values : <code>file, redis, none</code>
{{!}}file
{{!}}file
{{!}}-
{{!}} colspan="8"{{!}}'''Category: DAS'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}applicationHost (mandatory)
{{!}}Yes
{{!}}
{{!}}
{{!}}
{{!}}The server name Designer uses to generate the URL to the application. ORS and MCP fetch the application code and other resources from this URL.
{{!}}das.usw1.genhtcc.com
{{!}}localhost
{{!}}-
{{!}}applicationPort
{{!}}Yes
{{!}}
{{!}}
{{!}}
{{!}}The corresponding port to be used with applicationHost.
{{!}}80
{{!}}80
{{!}}-
{{!}}deployURL
{{!}}Yes
{{!}}
{{!}}
{{!}}
{{!}}This is normally not changed. It is the relative path to the workspace on DAS.
{{!}}/workspace
{{!}}/workspace
{{!}}-
{{!}} colspan="8"{{!}}'''Category: Digital'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}rootsSRL (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}If specified, this is used to filter which Root Categories to display when selecting Standard Responses.
{{!}}A REGular EXpression (REGEX).
{{!}}
{{!}}-
{{!}}maxFlowEntryCount (optional)
{{!}}Yes
{{!}}
{{!}}Yes
{{!}}flowsettings
{{!}}Specify how many times the same application can process a specific digital interaction.
{{!}}20
{{!}}20
{{!}}-
{{!}} colspan="8"{{!}}'''Category: External APIs'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}httpProxy (optional)
{{!}}Yes
{{!}}Yes
{{!}}Yes
{{!}}flowsettings
{{!}}Specify the proxy used for external requests and nexus API calls (if <code>enable_proxy</code> is <code>true</code>).
{{!}}http://[http://vpcproxy-000-int.geo.genprim.com/ vpcproxy-000-int.geo.genprim.com]:8080
{{!}}
{{!}}-
{{!}}redundantHttpProxy (optional)
{{!}}Yes
{{!}}Yes
{{!}}Yes
{{!}}flowsettings
{{!}}Specify the backup proxy used for external requests and nexus API calls (if <code>enable_proxy</code> is <code>true</code>), when httpProxy is down.
{{!}}http://[http://vpcproxy-000-int.geo.genprim.com/ vpcproxy-001-int.geo.genprim.com]:8080
{{!}}
{{!}}-
{{!}} colspan="8"{{!}}'''Category: Features'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}features
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}This is an object. See the '''5.5 Features''' section for a list of supported features.
{{!}}
{{!}}{

nexus: true,

enableBulkAudioImport: true

}
{{!}}-
{{!}} colspan="8"{{!}}'''Category: GWS'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}usehtcc
{{!}}Yes
{{!}}
{{!}}
{{!}}
{{!}}Set to <code>true</code> so that Designer works with GWS. If set to <code>false</code>, Designer defaults to a local mode and may be used temporarily if GWS is unavailable.
{{!}}true
{{!}}false
{{!}}-
{{!}}htccServer
{{!}}Yes
{{!}}
{{!}}
{{!}}
{{!}}GWS Server
{{!}}[http://gws-usw1-int.genhtcc.com/ gws-usw1-int.genhtcc.com]
{{!}}[http://gws-usw1-int.genhtcc.com/ gws-usw1-int.genhtcc.com]
{{!}}-
{{!}}htccport
{{!}}Yes
{{!}}
{{!}}
{{!}}
{{!}}GWS Port
{{!}}80
{{!}}80
{{!}}-
{{!}}ssoLoginUrl
{{!}}Yes
{{!}}
{{!}}
{{!}}
{{!}}URL of GWS authentication UI. Designer redirects to this URL for authentication.
{{!}}[https://gws-usw1.genhtcc.com/ https://gws-usw1.genhtcc.com]
{{!}}[https://gws-usw1.genhtcc.com/ https://gws-usw1.genhtcc.com]
{{!}}-
{{!}}maxConcurrentHTCCRequest (optional)
{{!}}Yes
{{!}}
{{!}}
{{!}}
{{!}}For batch operations to GWS, the max number of concurrent requests that Designer will send to GWS.
{{!}}5
{{!}}5
{{!}}-
{{!}}batchOperationResultTTL (optional)
{{!}}Yes
{{!}}
{{!}}
{{!}}
{{!}}For batch operations to GWS, the time, in milliseconds, for which duration Designer stores the results of a batch operation on the server, before deleting them.
{{!}}100000
{{!}}100000
{{!}}-
{{!}} colspan="8"{{!}}'''Category: Help'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}docsMicroserviceURL (optional)
{{!}}Yes
{{!}}
{{!}}
{{!}}
{{!}}URL for Designer documentation.
{{!}}
{{!}}https://docs.genesys.com/Documentation/PSAAS/Public/Administrator/Designer
{{!}}-
{{!}} colspan="8"{{!}}'''Category: IVR'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}recordingType (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}Specify the recording type to be used in Record block. Set as <code>GIR</code>. If the option is missing or blank, <code>Full Call Recording</code> type will be used.
{{!}}GIR
{{!}}GIR
{{!}}-
{{!}} colspan="8"{{!}}'''Category: Logging'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}
<source lang="json">
logging: {
designer: { level:

debug },

audit: { level: trace},

auditdebug: { level: debug },

cli: { level: debug }

}
</source>
(optional)
{{!}}Yes
{{!}}
{{!}}
{{!}}
{{!}}Specify Designer log levels. Each field has valid values - <code>trace, debug, info, warn, error, or fatal</code>.
'''designer''' - log level of Designer.

'''audit''' - log level of audit.

'''auditdebug''' - log level of audit debug, this will log detailed audit information.

'''cli''' - log level for cli commands executed on Designer.
{{!}}
<source lang="json">logging: {
designer: { level: debug},

audit: { level: trace },

auditdebug: { level: debug},

cli: { level: debug }

}
</source>
{{!}}
<source lang="json">
logging: {
designer: { level: debug },

audit: { level: trace },

auditdebug: { level: debug },

cli: { level: debug }

}
</source>
{{!}}-
{{!}} colspan="8"{{!}}'''Category: Nexus'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}url (optional)
{{!}}
{{!}}
{{!}}Yes
{{!}}nexus
{{!}}URL of Nexus that typically includes the API version path. For example, https://nexus-server/nexus/api/v3.
{{!}}
{{!}}[http://nex-dev.usw1.genhtcc.com/ http://nex-dev.usw1.genhtcc.com]
{{!}}-
{{!}}password (optional)
{{!}}
{{!}}
{{!}}Yes
{{!}}nexus
{{!}}nexus x-api-key created by Nexus deployment
{{!}}
{{!}}dc4qeiro13nsof569dfn234smf
{{!}}-
{{!}}enable_proxy (optional)
{{!}}
{{!}}
{{!}}Yes
{{!}}nexus
{{!}}Boolean value to indicate if httpProxy is used to reach Nexus.
{{!}}
{{!}}false
{{!}}-
{{!}}profile (optional)
{{!}}
{{!}}
{{!}}Yes
{{!}}nexus
{{!}}Enable Contact Identification via Nexus (for example, to enable Last Called Agent routing).
{{!}}
{{!}}
{{!}}-
{{!}} colspan="8"{{!}}'''Category: Process'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}port
{{!}}Yes
{{!}}
{{!}}
{{!}}
{{!}}Designer process port in the container. Normally, the default value should be left as is.
{{!}}8888
{{!}}3000
{{!}}-
{{!}} colspan="8"{{!}}'''Category: Provisioning'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}primarySwitch (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}Specify the primary switch name if more than one switch is defined for the tenant. Designer fetches and works with route points from this switch.
{{!}}
{{!}}us-west-1
{{!}}-
{{!}} colspan="8"{{!}}'''Category: Routing'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}ewtRefreshTimeout (optional)
{{!}}
{{!}}
{{!}}Yes
{{!}}flowsettings
{{!}}Specify the interval (in seconds) at which to refresh the Estimated Waiting Time when routing an interaction.
{{!}}5
{{!}}1
{{!}}-
{{!}} colspan="8"{{!}}'''Category: Redis'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}
<source lang="json">redis: {
host: "",
port: "",
tlsEnabled: true,
lockTimeout: 120,
listTimeout: 1800
}
</source> (optional)
{{!}}
{{!}}
{{!}}
{{!}}
{{!}}Used by Designer for resource index caching and multi-user collaboration locks on Designer resources.

It is a separate object and contains:

'''host''' - Redis host name.

'''port''' - Redis port.

'''tlsEnabled''' - TLS enabled or not.

'''lockTimeout''' - Timeout, in seconds, before a resource lock is released for an editing session of applications, modules, or data tables.

'''listTimeout''' - The cache expiry timeout (in seconds) of the application list and shared modules list. By default, it is 30 minutes. That is, any new application/modules created in the UI will be seen in the listing page after 30 mins. It can be reduced to a smaller value. This is to improve the page loading performance of the Applications and Shared Modules page. A better performance is achieved with a higher value.
{{!}}
<source lang="json">
redis: {
host: "",
port: "",
tlsEnabled: true,
lockTimeout: 120,
listTimeout: 1800
}
</source>
{{!}}
<source lang="json">
redis: {
host: redis.server.genhtcc.com,
port: 6379,
tlsEnabled: true,
lockTimeout: 120,
listTimeout: 1800
}
</source>
{{!}}-
{{!}} colspan="8"{{!}}'''Category: Security'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}zipFileSizeLimitInMegaBytes (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}Defines the maximum zipFile size limit (in megabytes) during bulk audio import.
{{!}}50
{{!}}No default.
{{!}}-
{{!}}disableCSRF (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}Disable CSRF attack protection.

http://cwe.mitre.org/data/definitions/352.html

By default, CSRF attack protection is enabled. It can be disabled by setting this flag to <code>true</code>.
{{!}}false
{{!}}false
{{!}}-
{{!}}disableSecureCookie (optional)
{{!}}Yes
{{!}}
{{!}}
{{!}}
{{!}}Disable the secure cookies header
{{!}}false
{{!}}false
{{!}}-
{{!}} colspan="8"{{!}}'''Category: Session'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}idleTimeout (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}Idle timeout, in seconds, before a user session is terminated while editing applications, modules, or data tables.
{{!}}840
{{!}}840
{{!}}-
{{!}}lockTimeout (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}Timeout, in seconds, before a resource lock is released, for an editing session of applications, modules, or data tables.
{{!}}120
{{!}}120
{{!}}-
{{!}}lockKeepalive (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}Interval, in seconds, before the client sends a ping to the server, to refresh the lock for an editing session of applications, modules, or data tables.
{{!}}15
{{!}}15
{{!}}-
{{!}} colspan="8"{{!}}'''Category: Workflow'''
{{!}}-
{{!}}Setting Name
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}DesignerEnv
{{!}}DesignerEnv Section
{{!}}Description
{{!}}Sample Value
{{!}}Default Value
{{!}}-
{{!}}maxBuilds (optional)
{{!}}Yes
{{!}}Yes
{{!}}
{{!}}
{{!}}Specify the maximum number of builds allowed per application.
{{!}}20
{{!}}20
{{!}}-
{{!}}enablePTE (optional)
{{!}}
{{!}}
{{!}}Yes
{{!}}flowsettings
{{!}}Boolean value to indicate if PTE objects are enabled at runtime.
{{!}}true
{{!}}false
{{!}}}
===5.5 Features===
The features specified here must be configured under the <code>features</code> object in the <code>flowsettings.json</code> file.

For example,

<source lang="json">
features: {

callbackv2: true,

..

..

}
</source>
{{NoteFormat|These features are configured only in the flowsettings.json file and the tenantsettings.json file, and not in DesignerEnv.|}}
{{{!}} class="wikitable"
{{!}}Category
{{!}}Feature Setting Name
{{!}}Mandatory
{{!}}flowsettings.json
{{!}}tenantsettings.json
{{!}}Description
{{!}}Default Value
{{!}}-
{{!}} rowspan="3"{{!}}Audio
{{!}}enableBulkAudioImport
{{!}}Optional
{{!}}Yes
{{!}}Yes
{{!}}Enable/disable the bulk audio import feature.
{{!}}false
{{!}}-
{{!}}grammarValidation
{{!}}Optional
{{!}}Yes
{{!}}yes
{{!}}If this feature is enabled, Designer will validate invalid grammar files during grammar upload and you can upload only valid grammar files (GRXML or Nuance compiled binary grammar files).
{{!}}false
{{!}}-
{{!}}<code>externalAudioSupport</code>
{{!}}Optional
{{!}}Yes
{{!}}Yes
{{!}}If this feature is enabled, a new audio type, External Audio, is available in the Play Message block. It accepts a single variable that contains a URL to the audio resource. MCP will fetch this resource directly and play it. The only supported value of '''Play As''' is ''Audio URI''. There is no automatic language switching for this audio type.
{{!}}false
{{!}}-
{{!}}Nexus
{{!}}nexus
{{!}}Optional
{{!}}Yes
{{!}}Yes
{{!}}Enable/disable the Nexus feature.
{{!}}false
{{!}}-
{{!}}Survey
{{!}}survey
{{!}}Optional
{{!}}Yes
{{!}}Yes
{{!}}Enable/disable the survey feature.
{{!}}true
{{!}}-
{{!}}Milestone
{{!}}enableImplicitModuleMilestones
{{!}}Optional
{{!}}Yes
{{!}}Yes
{{!}}Enable reporting each Shared Module call as an internal milestone. If disabled, Shared Module calls will not generate a milestone.
{{!}}false
{{!}}-
{{!}}Bots
{{!}}<code>enableDialogFlowCXBot</code>
{{!}}Optional
{{!}}Yes
{{!}}Yes
{{!}}When enabled, Dialogflow CX bot type is added to the bot registry and available for selection in the '''Bot provider''' drop-down when you configure a new bot.
{{!}}false
{{!}}}
|Status=No
}}{{Section
|sectionHeading=6. Logging
|anchor=logging
|alignment=Vertical
|structuredtext=Designer and DAS support console output (stdout) logging. Genesys recommends configuring console output logging to minimize the host IOPs and PVCs consumption by using log volumes. Console output logs can be extracted using log collectors like ''fluentbit/fluentd'' and ''Elasticsearch''.

Ensure the below setttings are configured in the respective '''values.yaml''' overrides for console logging:

#Designer <code>designerEnv.envs.DES_FILE_LOGGING_ENABLED = false</code>
#DAS <code>dasEnv.envs.DAS_FILE_LOGGING_ENABLED = false</code> <code>dasEnv.envs.DAS_STDOUT_LOGGING_ENABLE = true</code>

===6.1 Log levels===
Post deployment, Designer and DAS log levels can be modified as follows:

====6.1.1 Designer====

#Configure the <code>logging</code> setting in the flowsettings override ('''flowsettings.yaml''') - Refer to section ''5.4 Configuration settings reference table'' for option descriptions.
#Execute the steps in the ''Flowsettings.json update'' section (''8.2.2 Designer deployment process'') for the changes to take effect .

====6.1.2 DAS====

#Configure the <code>dasEnv.envs.DAS_LOG_LEVEL</code> setting in the Helm '''das-values.yaml''' file. Refer to section ''4.2 DAS deployment settings'' for setting descriptions.
#Execute the steps in the ''Upgrade non production color'' section (''8.2.3 DAS deployment process''). The same DAS version running in production can be used for the upgrade,
#Execute the steps in the ''Cutover'' section (''8.2.3 DAS deployment process'').
|Status=No
}}{{Section
|sectionHeading=7. Platform / Configuration Server and GWS settings
|anchor=placonset
|alignment=Vertical
|structuredtext=This section explains the Configuration Server objects and settings required for Designer.

===7.1 Create Roles for Designer===
Designer uses roles and access groups to determine permissions associated with the logged-in user. To enable this, you must make these changes in GAX or CME.

Designer supports a number of bundled roles suitable for various levels of users.

*'''DesignerDeveloper''' - Most users fall into this category. These users can create Designer applications, upload audio, and create business controls. They have full access to Designer Analytics.

*'''DesignerBusinessUser''' - These users cannot create objects but they can manage them (for example, upload audio, change data tables, and view analytics).

*'''DesignerAnalytics''' - These users only have access to Designer Analytics.

*'''DesignerAdmin''' - These users can set up and manage partitions associated with users and Designer objects.
*'''DesignerOperations''' - Users with this role have full access to all aspects of the Designer workspace. This includes the '''Operations''' menu (normally hidden), where they can perform advanced operational and maintenance tasks.

To create these roles, import the '''.conf''' files included in the '''Designer Deployment Manifest''' package. They are located in the '''packages/roles/''' folder.

In addition, ensure the following for user accounts that need access to Designer:

*The user must have read permissions on its own Person object.
*Users must be associated with one or more roles via access groups.
*The on-Premises user must have at least read access on the user, access group(s), and roles(s).
*The access groups must have read/write permissions to the CME folders - Scripts and Transactions.

===7.2 Create the DesignerEnv transaction list===
Designer requires a transaction list for configuration purposes as described in other sections of this document. To set this up:

#Create a transaction list called '''DesignerEnv'''.
#Import the file '''configuration/DesignerEnv.conf''', located in the Designer Deployment Manifest package.
#Edit any values according to the descriptions provided in the '''Designer settings''' section.
#Save the list.
#Ensure Designer users have at least read access to the '''DesignerEnv''' transaction list.

===7.3 Platform Settings===
The platform settings listed below must be configured if the Designer application is used for voice calls.

{{{!}} class="wikitable"
{{!}}Component
{{!}}Config Key
{{!}}Value
{{!}}Description
{{!}}-
{{!}}SIP Switch -> Voip Services -> msml service
{{!}}userdata-map-format
{{!}}sip-headers-encoded
{{!}}Option needs to set to pass JSON data as user data in SIPS.
{{!}}-
{{!}}SIP Switch -> Voip Services -> msml service
{{!}}userdata-map-filter
{{!}}*
{{!}}To allow userdata passing to MSML service
{{!}}-
{{!}} rowspan="7"{{!}}SIPServer --> TServer
{{!}}divert-on-ringing
{{!}}false
{{!}}RONA is handled by the platform.
{{!}}-
{{!}}agent-no-answer-timeout
{{!}}12
{{!}}
{{!}}-
{{!}}agent-no-answer-action
{{!}}notready
{{!}}
{{!}}-
{{!}}agent-no-answeroverflow
{{!}}""
{{!}}no value, empty.
{{!}}-
{{!}}after-routing-timeout
{{!}}24
{{!}}
{{!}}-
{{!}}sip-treatments-continuous
{{!}}true
{{!}}
{{!}}-
{{!}}msml-record-support
{{!}}true
{{!}}To allow routed calls recording via the Media Server
{{!}}-
{{!}}Switch object annex --> gts
{{!}}ring-divert
{{!}}1
{{!}}
{{!}}-
{{!}}URS
{{!}}'http' port, protocol = 'http'
{{!}}
{{!}}Required only for Route Agent block to work.
{{!}}-
{{!}}ORS --> orchestration
{{!}}new-session-on-reroute
{{!}}false
{{!}}Required for SIPS Default Routing ([https://intranet.genesys.com/pages/viewpage.action?pageId=55813481 Default Routing handling (Voice)])
{{!}}-
{{!}}MCP
{{!}}[vxmli] transfer.allowed
{{!}}TRUE
{{!}}Required for Transfer block (allows VXML Transfer in MCP)
{{!}}-
{{!}}MCP
{{!}}[cpa] outbound.method
{{!}}NATIVE
{{!}}Required for Transfer block (allow CPA detection for Transfer )
{{!}}-
{{!}}UCS
{{!}}[cview] enabled
{{!}}TRUE
{{!}}Enables Customer Context Services
{{!}}}

===7.4 GWS Configuration===

====7.4.1 Create Contact Center====
Create a contact center in GWS if it is not already created. Refer to the [https://docs.genesys.com/Documentation/HTCC/8.5.2/API/Welcome GWS documentation] for more information on this.

====7.4.2 Create GWS Client====
Create new GWS client credentials if they are not already created . Refer to the [https://docs.genesys.com/Documentation/HTCC/8.5.2/API/Welcome GWS documentation] for more information on this.
|Status=No
}}{{Section
|sectionHeading=8. Deployment
|anchor=dep
|alignment=Vertical
|structuredtext=This section describes the deployment process for Designer and DAS.

===8.1 Preparation===
Before you deploy Designer and DAS using Helm charts, complete the following preparation steps:

#Ensure the Helm client is installed.
#Set up an Ingress controller, if not already done.
#Setup an NFS server, if not already done.
#Create Persistent Volumes - a sample YAML file is provided in the Designer manifest package.
#Download the Designer and DAS docker images and push to the local docker registry.
#Download the Designer manifest package and extract to the current working directory.
#Configure Designer and DAS value overrides (designer-values.yaml and das-values.yaml) - please ensure the mandatory settings are configured. If the blue-green deployment process is used, Ingress settings are explained in the following section.

===8.2 Blue-Green deployment===
Blue-Green deployment is a release management technique that reduces risk and minimizes downtime. It uses two production environments, known as Blue and Green or active and inactive, to provide reliable testing, continuous no-outage upgrades, and instant rollbacks. When a new release needs to be rolled out, an identical deployment of the application will be created using a Helm package and after the testing is completed, the traffic is moved to the newly created deployment, which becomes the ACTIVE environment, and the old environment becomes INACTIVE. This way, a fast rollback is possible by just changing route if a new issue is found with live traffic. The old inactive deployment can be removed once the new active deployment becomes stable.

The service cutover is done by updating the Ingress rules. The below diagram shows the high level approach on how the traffic can be routed to Blue and Green deployments with Ingress rules.

[[File:BlueGreenDeployment.png|border]]

====8.2.1 Preparation for Blue-Green deployment====
Before you deploy Designer and DAS using the Blue-Green deployment strategy, complete the following preparation steps:

#Configure the Ingress host names for Designer. Create 3 host names as shown below. The Blue service host name must contain the string ''blue'', for example, <code>designer.blue.genhtcc.com</code> or <code>designer-blue.genhtcc.com</code>. The Green service host name must contain the string ''green'', for example, <code>designer.green.genhtcc.com</code> or <code>designer-green.genhtcc.com</code>. The Blue/Green services can be accessed separately with the Blue/Green host names as shown in this example: <code>designer.genhtcc.com</code> (production host URL used for external access). <code>designer.blue.genhtcc.com</code> (URL for Blue service testing). <code>designer.green.genhtcc.com</code> (URL for Green service testing).
#Configure the host names in the '''designer-values.yaml''' file under ingress. Annotations and paths can be modified based on the requirement. For example, <code>ingress:</code> <code>enabled: true</code> <code>annotations: {}</code> <code>paths: [/]</code> <code>hosts:</code> <code>- designer.genhtcc.com</code> <code>- designer.blue.genhtcc.com</code> <code>- designer.green.genhtcc.com</code>
#Configure the Ingress host names for DAS. Create 3 host names as shown below. The Blue service host name must contain the string ''blue'', for example, <code>das.blue.genhtcc.com</code> or <code>das-blue.genhtcc.com</code>. The Green service host name must contain the string ''green'', for example, <code>das.green.genhtcc.com</code> or <code>das-green.genhtcc.com</code>. he Blue/Green services can be accessed separately with the Blue/Green host names as shown in this example: <code>das.genhtcc.com</code> (the production host URL used for external access). <code>das.blue.genhtcc.com</code> (URL for Blue service testing). <code>das.green.genhtcc.com</code> (URL for Blue service testing).
#Configure the host names in the '''das-values.yaml''' file under ingress. Annotations and paths can be modified based on the requirement. For example, <code>ingress:</code> <code>enabled: true</code> <code>annotations: {}</code> <code>paths: [/]</code> <code>hosts:</code> <code>- das.genhtcc.com</code> <code>- das.blue.genhtcc.com</code> <code>- das.green.genhtcc.com</code>

====8.2.2 Designer deployment process====

====Initial deployment====
The resources's ingress and persistent volume claims (PVC) must be created initially before deploying the Designer service as these resources are shared between the Blue/Green services and must be created at the very beginning of the deployment. They will not be needed for subsequent upgrades. The required values are passed using the <code>SET</code> command as shown below or by modifying the '''values.yaml''' file.

#Create Persistent Volume Claims required for the Designer service (assuming the volume service name is <code>designer-volume</code>): <code>helm upgrade --install designer-volume -f designer-values.yaml designer-9.0.xx.tgz --set deployment.strategy=volume</code> Note: The overrides passed as an argument to the above helm upgrade command: <code>deployment.strategy=volume</code> - indicates that this helm install will create persistent volume claim.
#Create ingress rules for the Designer service (assuming the ingress service name is <code>designer-ingress</code>): <code>helm upgrade --install designer-ingress -f designer-values.yaml designer-9.0.xx.tgz --set deployment.strategy=ingress --set-string deployment.color=green</code> Note: The overrides passed as an argument to the above helm upgrade command: <code>deployment.strategy=ingress</code> - indicates that this helm install will create ingress rules for the Designer service. <code>deployment.color=green</code> - indicates that the current production instance (active) color is Green.
#Deploy the Designer service to the color selected in step 2. In this case, Green is selected and assuming the service name is <code>designer-green</code>: <code>helm upgrade --install designer-green -f designer-values.yaml designer-9.0.xx.tgz --set deployment.strategy=service --set desImage.tag=9.0.1xx.xx.xx --set-string deployment.color=green</code> Note: The overrides passed as an argument to the above helm upgrade command: <code>deployment.strategy=service</code> - indicates that the Designer service will be installed. <code>desImage.tag=9.0.1xx.xx.xx</code> - indicates the Designer version to be installed, for example, 9.0.116.07.10. <code>deployment.color=green</code> - indicates that the Green color service will be installed.

====Upgrade non-production color====

#Identify the current production color by checking the Designer ingress rules (<code>kubectl describe ingress designer-ingress</code>). Green is the production color in the below example as the production host name points to the Green service. [[File:Upgrade Non-Production Color.png|border]]
#Deploy the Designer service into the non-production color. In the above example, Blue is the non-production color (assuming the service name is <code>designer-blue</code>): <code>helm upgrade --install designer-blue -f designer-values.yaml designer-9.0.xx.tgz --set deployment.strategy=service --set desImage.tag=9.0.1xx.xx.xx --set-string deployment.color=blue</code> Note: The overrides passed as an argument in the above helm upgrade: <code>deployment.strategy=service</code> - indicates that the Designer service will be installed. <code>desImage.tag=9.0.1xx.xx.xx</code> - indicates the Designer version to be installed, for example, 9.0.116.08.12. <code>deployment.color=blue</code> - indicates that the Blue color service will be installed.
#The non-production color can be accessed with the non-production host name (for example - <code>designer.blue.genhtcc.com</code>), any testing can be done using this URL.

====Cutover====
Once testing is completed on the non-production color, traffic can be moved to the new version by updating the ingress rules.

#Update the Designer Ingress with the new deployment color by running the below command (in this case, Blue is the new deployment color, that is, the non-production color): <code>helm upgrade --install designer-ingress -f designer-values.yaml designer-9.0.xx.tgz --set deployment.strategy=ingress --set-string deployment.color=blue</code> Note: The overrides passed as an argument to the above helm upgrade command: <code>deployment.strategy=ingress</code> - indicates that this helm install will create ingress rules for the Designer service. <code>deployment.color=blue</code> - indicates that the current production (active) color is Blue.
#Verify the ingress rules by executing the command <code>kubectl describe ingress designer-ingress</code>. The production host name should point to the new color service.

====Workspace upgrade====
Workspace resources must be upgraded after cutover. This will upgrade the system resources in the Designer workspace.

#Log in to one of the Designer pods with the command: <code>kubectl exec -it <pod_name> bash</code>.
#Execute the migration command (this will create new directories/new files introduced in the new version): <code>node ./bin/cli.js workspace-upgrade -m -t <contact_center_id></code>
#Execute the workspace resource upgrade command (this will upgrade system resources, such as system service PHP files, internal audio files, and callback resources): <code>node ./bin/cli.js workspace-upgrade -t <contact_center_id></code> <code>contact_center_id</code> is the contact center ID created in GWS for this tenant. The workspace resources are located within the contact center ID folder ''(/workspaces/<ccid>/workspace)''.{{NoteFormat|The above steps - upgrade non production color, cutover, and workspace upgrade will also be used for further upgrades.|}}

====Flowsettings.json update====
Post deployment, the '''flowsettings.json''' file can be modified via helm install using the below steps:

#Download the current '''flowsettings.json''' file from the location: ''<workspace>/designer/flowsettings.json''.
#Modify the necessary settings (refer to section ''5.4 Configuration settings reference table'').
#Create a new YAML file, for example, '''flowsettings.yaml'''.
#Copy and paste the above modified '''flowsettings.json''' content in the new '''flowsettings.yaml''' file: <code>flowsettings: <paste the entire flowsettings.json content></code> For example: <code>flowsettings: {</code> <code>port:8888,</code> <code>usehtcc:true,</code> <code>htccserver:gws-int-genhtcc.com,</code> <code>htccport:80,</code> <code>....</code> <code>....</code> <code>}</code>
#Run the below helm upgrade command on the non-production color service. It can be done as part of Designer upgrade by passing the '''flowsettings.yaml''' in the extra argument <code>--values</code>. In this case, the new Designer version can be used for the upgrade. If it is only a '''flowsettings.json''' update, the same Designer version will be used. <code>helm upgrade --install designer-blue -f designer-values.yaml designer-9.0.xx.tgz --set deployment.strategy=service --set desImage.tag=9.0.1xx.xx.xx --set-string deployment.color=blue --values flowsettings.yaml</code> The non-active color Designer will have updated settings after the above upgrade.
#Once testing is completed on the non-production service, perform the cutover steps as mentioned in the Cutover section. Now, the production service will contain the changed settings.

====Rollback====

*If any blocking issues are noticed in the current production service, traffic can be rolled back to the previous active color by updating the ingress rules: <code>helm upgrade --install designer-ingress -f designer-values.yaml designer-9.0.xx.tgz --set deployment.strategy=ingress --set-string deployment.color=green</code> Rollback of workspace resources is generally not required as the workspace resources shipped with Designer are backward and forward compatible. If required, the workspace can be upgrade from the old version, but it is not necessary. Future new version upgrades must run the workspace upgrade as per the normal process. Rollback of applications and shared modules is also not required as these resources are also backward and forward compatible with Designer.

====8.2.3 DAS deployment process====

====Initial deployment====
The ingress must be created initially before deploying the DAS service as it is shared between the Blue/Green services and must be created at the very beginning of the deployment. It will not be needed for subsequent upgrades. The required values are passed using the <code>SET</code> command as shown below or by modifying the '''values.yaml''' file.

#Create ingress rules for the Designer service (assuming the ingress service name is <code>das-ingress</code>): <code>helm upgrade --install das-ingress -f das-values.yaml das-9.0.xx.tgz --set deployment.strategy=ingress --set-string deployment.color=green</code> Note: The overrides passed as an argument to the above helm upgrade command: <code>deployment.strategy=ingress</code> - indicates that this helm install will create ingress rules for the DAS service. <code>deployment.color=green</code> - indicates that the current production instance (active) color is Green.
#Deploy the DAS service to the color selected in step 1. In this case, Green is selected and assuming the service name is <code>das-green</code>: <code>helm upgrade --install das-green -f das-values.yaml das-9.0.xx.tgz --set deployment.strategy=service --set dasImage.tag=9.0.1xx.xx.xx --set-string deployment.color=green</code> Note: The overrides passed as an argument to the above helm upgrade command: <code>deployment.strategy=service</code> - indicates that the DAS service will be installed. <code>dasImage.tag=9.0.1xx.xx.xx</code> - indicates the DAS version to be installed, for example, 9.0.111.04.4. <code>deployment.color=green</code> - indicates that the Green color service will be installed.

====Upgrade non-production color====

#Identify the current production color by checking the DAS ingress rules (<code>kubectl describe ingress das-ingress</code>). Green is the production color in the below example as the production host name points to the Green service. [[File:Upgrade non-production color - DAS.png|border]]
#Deploy the DAS service into the non-production color. In the above example, Blue is the non-production color (assuming the service name is <code>das-blue</code>): <code>helm upgrade --install das-blue -f das-values.yaml das-9.0.xx.tgz --set deployment.strategy=service --set dasImage.tag=9.0.1xx.xx.xx --set-string deployment.color=blue</code> Note: The overrides passed as an argument to the above helm upgrade command: <code>deployment.strategy=service</code> - indicates that the DAS service will be installed. <code>dasImage.tag=9.0.1xx.xx.xx</code> - indicates the DAS version to be installed , for example, 9.0.111.05.5. <code>deployment.color=blue</code> - indicates that the Blue color service will be installed.
#The non-production color can be accessed with the non-production host name (for example - <code>das.blue.genhtcc.com</code>), any testing can be done using this URL.

====Cutover====
Once testing is completed on the non-production color, traffic can be moved to the new version by updating the ingress rules.

#Update the DAS Ingress with the new deployment color by running the below command (in this case, Blue is the new deployment color, that is, the non-production color): <code>helm upgrade --install das-ingress -f das-values.yaml das-9.0.xx.tgz --set deployment.strategy=ingress --set-string deployment.color=blue</code> Note: The overrides passed as an argument to the above helm upgrade command: <code>deployment.strategy=ingress</code> - indicates that this helm install will create ingress rules for the DAS service. <code>deployment.color=blue</code> - indicates that the current production (active) color is Blue.
#Verify the ingress rules by running the command kubectl describe ingress das-ingress. The production host name should point to the new color service.{{NoteFormat|The above steps - upgrade non production color and cutover will also be used for further upgrades.|}}

====Rollback====
If any blocking issues are noticed in the current production service, traffic can be rolled back to the previous active color by updating the ingress rules:

<code>helm upgrade --install das-ingress -f das-values.yaml das-9.0.xx.tgz --set deployment.strategy=ingress --set-string deployment.color=green</code>

===8.3 Rolling upgrade===
A rolling upgrade is not recommended. Use the Blue/Green upgrade procedure.

===8.4 Uninstall===
To uninstall a service/volume/ingress rules:

<code>helm uninstall <service-name></code> 
|Status=No
}}{{Section
|sectionHeading=9. Enabling optional features
|anchor=enopfts
|alignment=Vertical
|structuredtext====9.1 Enable Designer Analytics and Audit Trail===
Post Designer deployment, features such as Analytics and Audit Trail can be enabled by performing the below steps.{{NoteFormat|Ensure Elasticsearch is deployed before proceeding.|}}

====9.1.1 Designer changes====

#Configure the following settings in flowsettings override ('''flowsettings.yaml''') - Refer to section ''5.4 Configuration settings reference table'' for option descriptions.
#*enableAnalytics: true
#*enableESAuditLogs: true
#*esServer
#*esPort
#*esUrl
#Configure the below setting in the DesignerEnv transaction list: <code>ReportingURL</code> in the '''reporting''' section.
#Perform the steps in the ''Flowsettings.json update'' section (''8.2.1 Designer deployment process'').

====9.1.2 DAS changes====

#Configure the following settings in the helm '''das-values.yaml''' file. Refer to the ''4.2 DAS deployment settings'' section for setting descriptions. <code>dasEnv.envs.DAS_SERVICES_ELASTICSEARCH_ENABLED = true</code> <code>dasEnv.envs.DAS_SERVICES_ELASTICSEARCH_HOST</code> <code>dasEnv.envs.DAS_SERVICES_ELASTICSEARCH_PORT</code>
#Perform the steps in the ''Upgrade non production color'' section (''8.2.2 DAS deployment process''). The same DAS version running in production can be used for the upgrade.
#Perform the steps in the ''Cutover'' section (''8.2.2 DAS deployment process'').
|Status=No
}}{{Section
|sectionHeading=10. Cleanup
|anchor=cleanup
|alignment=Vertical
|structuredtext====10.1 Elasticsearch maintenance recommendations===
To help you better manage your indexes and snapshots, and to prevent too many indexes from creating an overflow of shards, Genesys recommends that you set up a scheduled execution of Elasticsearch Curator with the following two actions:

*Delete indexes older than the given threshold according to the index name and mask.
**<code>sdr-*</code> (3 months)
**<code>audit-*</code> (12 months)

*Make a snapshot of each index:
**<code>sdr-*</code> (yesterday and older)
**<code>audit-*</code>
**<code>kibana-int-*</code>
|Status=No
}}{{Section
|sectionHeading=11. Limitations
|anchor=limits
|alignment=Vertical
|structuredtext=Designer currently supports multi-tenancy provided by the tenant Configuration Server. That is, each tenant should have a dedicated Configuration Server, and Designer can be shared across the multiple tenants.
|Status=No
}}
}}

PrivateEdition/Current/PEGuide/ManageServices

2022-03-22T14:17:48Z

MPandian: Published

{{Article
|Standalone=No
|DisplayName=Downloading your Genesys Multicloud CX containers
|Context=Genesys Multicloud CX containers are accessible through JFrog. You can also automate downloads to set up a Continuous Delivery (CD) pipeline.
|ComingSoon=No
|Platform=Private Edition
|Section={{Section
|sectionHeading=Overview
|anchor=ovrvw
|alignment=Vertical
|structuredtext=Genesys uses JFrog to deliver and distribute its release containers. JFrog is a hybrid, universal, end-to-end devops platform. It is a fully automated platform for distributing software releases from code to production. You can pull new releases from the JFrog Artifactory Edge repository.

Use the information in this topic to set up your Continuous Delivery (CD) pipeline.{{NoteFormat|Your CD pipeline must accommodate any necessary steps to meet your corporate requirements such as, performing security scans and validation testing.|}}The Engage private edition release containers can be accessed through either of the following:

*Artifactory Edge Portal
*Artifactory Edge API
*Command Line Interfaces (CLI) for Docker, Helm, or cURL.

You can set up automated downloads for any of the available repositories using the '''Set Me Up''' screen for the corresponding repository.
|Status=No
}}{{Section
|sectionHeading=Accessing repositories on JFrog
|anchor=accjf
|alignment=Vertical
|structuredtext=#Navigate to the following URL using your browser: https://pureengageuse1.jfrog.io/ui/login/
#Use your JFrog credentials from Genesys to log in.
{{NoteFormat|Credentials to access the Genesys repository on JFrog are automatically emailed to new accounts. Please contact your Genesys Account Representative if you have not received your credentials.|}}[[File:JFrogWelcome.png|border|700x700px]] Artifactory Edge contains the following six Genesys repositories:{{NoteFormat|A virtual repository aggregates several repositories with the same package type under a common URL.|}}
{{{!}} class="wikitable"
{{!}}+
!Name of repository
!Type of artifacts
{{!}}-
{{!}}helm-multicloud-local
{{!}}Helm charts local repository
{{!}}-
{{!}}files-multicloud-local
{{!}}Configuration files local repository
{{!}}-
{{!}}docker-multicloud-local
{{!}}Docker local repository
{{!}}-
{{!}}helm-multicloud
{{!}}Helm virtual repository
{{!}}-
{{!}}files-multicloud
{{!}}Files virtual repository
{{!}}-
{{!}}docker-multicloud
{{!}}Docker virtual repository
{{!}}}

Once you login, select '''Artifacts''' from the '''Artifactory Edge''' menu from the left pane. All repositories available for download from Genesys are listed.[[File:JFrogEdgeRep.png|border|700x700px]]

You can expand each repository and navigate to any of the files within a folder to view its properties on the left pane. Note that as all available files are listed, you must navigate to the one you require based on the date and version number.

[[File:JFrogEdgeRep2.png|border|700x700px]]

The '''Distribution''' view lists all files IPs and the files within each IP.

[[File:JFrogDistView.png|border|700x700px]]

You can set up automated downloads for any repository using the '''Set Me Up''' screen for the corresponding repository.
|Status=No
}}{{Section
|sectionHeading=Signing up for update notifications
|anchor=sgnupdnot
|alignment=Vertical
|structuredtext=When you log in for the first time, sign up for email notifications on any updates to the packages in the repository. Note that you can set this up later too. But we recommend you set this up in order to receive regular notifications on any updates to the packages.

#Click on your username at the top right corner of the screen.
#Select the '''Edit Profile''' option from the drop-down. [[File:UpdNot1.png|border|700x700px]]
#Enter your password and click '''Unlock'''. [[File:UpdNot2.png|border|700x700px]]
#Verify your email address. Update if required and click '''Save'''. [[File:UpdateNot3.png|border|700x700px]]
#Navigate to the repository for which you want update notifications.
#Click '''Actions''' at the top right corner, and then click '''Follow''' from the drop-down. [[File:UpdNot4.png|border|700x700px]] A confirmation message is displayed. [[File:UpdNot5.png|border|700x700px]] 
{{NoteFormat|Update notifications are accumulated across 1-minute intervals and sent in a single email.|}}
|Status=No
}}{{Section
|sectionHeading=Setting up automated downloads
|anchor=setupautdown
|alignment=Vertical
|structuredtext=You can integrate with external tools to automate your downloads from JFrog. The '''Set Me Up''' screen provides quick access to information on how to configure your different clients to work with the corresponding repositories you have created.

*Select a repository and click '''Set Me Up''' on the top right corner to view its '''Set Me Up''' screen. [[File:SetMeUp1.png|border]] [[File:SetMeUp2.png|border]]

 

===Downloading using Docker CLI===

#On the '''Set Me Up''' screen, select '''Docker''' from the '''Package Type''' drop-down. [[File:Docker.png|border]]
#Provide the following docker login command in the '''General''' section as shown below: <code>docker login pureengageuse1-docker-premise.jfrog.io</code>
#Provide your Artifactory username and password or the API key in the provided input field.
#To manually set your credentials, or if you are using Docker v1, copy the following snippet to your '''~/.docker/config.json''' file: <source>{
"auths": {
"https://pureengageuse1-docker-premise.jfrog.io" : {
"auth": "<USERNAME>:<PASSWORD> (converted to base 64)", "email": "youremail@email.com"
}
}
}</source> 
#To pull an image use the docker pull command specifying the docker image and tag names: <code>docker pull pureengageuse1-docker-premise.jfrog.io/<DOCKER_REPOSITORY>:<DOCKER_TAG></code>

===Downloading using the Helm CLI===
To work with Helm repositories, you must have a Helm client installed and configured before you perform the following steps:{{NoteFormat|You must use Helm version 2.9.0 or a higher version that supports authentication against Artifactory.|}}

#On the '''SET ME UP''' screen, select '''Helm''' from the '''Package Type''' drop-down. [[File:Helm.png|border]]
#In the '''General''' section, set up your default Artifactory Helm repository/registry with the following command: <code>helm repo add helm-premise <nowiki>https://pureengageuse1.jfrog.io/artifactory/helm-premise</nowiki> --username <USERNAME> --password <PASSWORD></code>
#In the '''Resolve''' section, provide the following commands to install a Helm Chart from the selected repository using your Helm command line client: <code>helm repo update</code> <code>helm install helm-premise/[chartName]</code>
|Status=No
}}{{Section
|sectionHeading=Downloading using cURL
|anchor=downcurl
|alignment=Vertical
|structuredtext=You can also download a package from the Edge Artifactory by accessing its API through a cURL command.

For example,

<code>curl -utest-use1edge:AP3joWh1WJkH39WbiGmvMUBCBD8 -O "[https://pureengageuse1.jfrog.io/artifactory/helm-premise/cxcontact-022.03.121.tgz" https://pureengageuse1.jfrog.io/artifactory/helm-premise/cxcontact-022.03.121.tgz"]</code>.
|Status=No
}}{{Section
|sectionHeading=Downloading manually
|anchor=downman
|alignment=Vertical
|structuredtext=JFrog Artifactory also supports manual downloads if you do not want to set up a CD pipeline.

#Select the required artifact using the ''Tree'' browsing method or the ''Simple'' browsing method.
#Click the '''Deploy''' option on the top right corner of the screen. [[File:ManualDownload.png|border]]

For more information on browsing through the artifacts in the Artifact Repository Browser, refer to the [https://www.jfrog.com/confluence/display/JFROG/Browsing+Artifacts Browsing Artifacts] topic on the JFrog documentation site.
|Status=No
}}{{Section
|sectionHeading=Additional reading material
|anchor=addreadmat
|alignment=Vertical
|structuredtext=*JFrog Artifactory Edge (an ''Edge node'') is an edition of JFrog Artifactory with features customized to serve the primary purpose of distributing software to a runtime system such as a data center, a point-of-sale, or even a mobile device. For more information, refer to the [https://www.jfrog.com/confluence/display/JFROG/JFrog+Artifactory+Edge JFrog Artifactory Edge] topic on the JFrog documentation site.
*Local repositories are physical, locally-managed repositories into which you can deploy artifacts. Whereas, a virtual repository (or repository group) aggregates several repositories with the same package type under a common URL. For more information, refer to the [https://www.jfrog.com/confluence/display/JFROG/Repository+Management Repository Management] topic on the JFrog documentation site.
|Status=No
}}
}}

File:UpdNot5.png

2022-03-22T14:15:03Z

MPandian: MPandian uploaded a new version of File:UpdNot5.png

Update notifications step 5.

File:UpdNot4.png

2022-03-22T14:14:48Z

MPandian: MPandian uploaded a new version of File:UpdNot4.png

Update notifications step 4.

File:UpdNot2.png

2022-03-22T14:14:29Z

MPandian: MPandian uploaded a new version of File:UpdNot2.png

Update notifications step 2.

File:UpdNot1.png

2022-03-22T14:14:15Z

MPandian: MPandian uploaded a new version of File:UpdNot1.png

Update notifications step 1.

File:UpdateNot3.png

2022-03-22T14:14:01Z

MPandian: MPandian uploaded a new version of File:UpdateNot3.png

Update notifications step 3.

File:SetMeUp2.png

2022-03-22T14:13:45Z

MPandian: MPandian uploaded a new version of File:SetMeUp2.png

SetMeUp2

File:SetMeUp1.png

2022-03-22T14:13:30Z

MPandian: MPandian uploaded a new version of File:SetMeUp1.png

SetMeUp1

File:ManualDownload.png

2022-03-22T14:13:14Z

MPandian: MPandian uploaded a new version of File:ManualDownload.png

ManualDownload

File:JFrogEdgeRep2.png

2022-03-22T14:12:53Z

MPandian: MPandian uploaded a new version of File:JFrogEdgeRep2.png

File:JFrogEdgeRep.png

2022-03-22T14:12:37Z

MPandian: MPandian uploaded a new version of File:JFrogEdgeRep.png

JFrog repositroy.

File:JFrogDistView.png

2022-03-22T14:12:20Z

MPandian: MPandian uploaded a new version of File:JFrogDistView.png

JFrog distribution view.

File:Helm.png

2022-03-22T14:12:01Z

MPandian: MPandian uploaded a new version of File:Helm.png

Helm set me up

File:Docker.png

2022-03-22T14:11:32Z

MPandian: MPandian uploaded a new version of File:Docker.png

Docker set me up

DES/Current/DESPEGuide/EnableFeatures

2022-03-14T12:01:58Z

MPandian: Published

{{Article
|Standalone=No
|DisplayName=Enable optional features
|TocName=Enable optional features
|Context=Learn how to enable optional features in Designer post deployment.
|ComingSoon=No
|Section={{Section
|sectionHeading=Enable Designer Analytics and Audit Trail
|alignment=Vertical
|structuredtext=Post Designer deployment, features such as Analytics and Audit Trail can be enabled by performing the below steps.{{NoteFormat|Ensure Elasticsearch is deployed before proceeding.|}}

===Designer===

#Configure the following settings in flowsettings override ('''flowsettings.yaml''') - Refer to the table in the {{Link-SomewhereInThisVersion|manual=DESPEGuide|topic=Configure#postdepconf|display text=Post deployment Designer configuration settings}} section for option descriptions.
#*enableAnalytics: true
#*enableESAuditLogs: true
#*esServer
#*esPort
#*esUrl
#Configure the below setting in the DesignerEnv transaction list: <code>ReportingURL</code> in the '''reporting''' section.
#Perform the steps in the ''Updating the'' f''lowsettings file'' section in {{Link-SomewhereInThisVersion|manual=DESPEGuide|topic=Deploy|display text=Post deployment procedures}}.

===DAS===

#Configure the following settings in the helm '''das-values.yaml''' file. For setting descriptions, refer to the ''DAS deployment settings'' section in {{Link-SomewhereInThisVersion|manual=DESPEGuide|topic=Configure|display text=Deployment configuration settings}}. <code>dasEnv.envs.DAS_SERVICES_ELASTICSEARCH_ENABLED = true</code> <code>dasEnv.envs.DAS_SERVICES_ELASTICSEARCH_HOST</code> <code>dasEnv.envs.DAS_SERVICES_ELASTICSEARCH_PORT</code>
#Execute the steps in the {{Link-SomewhereInThisVersion|manual=DESPEGuide|topic=Deploy|display text=Upgrade}} section in the DAS deployment process for the Blue-Green strategy. The same DAS version running in production can be used for the upgrade.
#Execute the steps in the {{Link-SomewhereInThisVersion|manual=DESPEGuide|topic=Deploy#dascutover|display text=Cutover}} section in the DAS deployment process for the Blue-Green strategy.
|Status=No
}}{{Section
|sectionHeading=Enable Personas
|alignment=Vertical
|structuredtext=You can enable the Personas feature in Designer by following the below steps.
===Deploy personas.json===

*Deploy the '''personas.json''' file in the workspace location, <code>/workspace/{tenantID}/workspace/personas/personas.json.</code>
*Create the '''personas''' directory if it does not exist.

Given below is a sample '''personas.json''' file:<source>[
{
"id": "1",
"name": "Samantha",
"gender": "female",
"tags": ["female", "middle-age", "default"],
"displayPersona": "female, 30-40s, professional, calm",
"voice": [{
"name": "samantha",
"language": "en-US",
"ttsname": "Samantha",
"ttsengine": "NuanceTTS",
"displayName": "Samantha"
}, {
"name": "karen",
"language": "en-AU",
"ttsname": "Karen",
"ttsengine": "NuanceTTS",
"displayName": "Karen"
}, {
"name": "amelie",
"language": "fr-CA",
"ttsname": "Amelie",
"ttsengine": "NuanceTTS",
"displayName": "Amelie"
}, {
"name": "paulina",
"language": "es-MX",
"ttsname": "Paulina",
"ttsengine": "NuanceTTS",
"displayName": "Paulina"
}
],
"digital": {},
"email": {},
"chat": {},
"web": {}
},
{
"id": "2",
"name": "Tom",
"gender": "male",
"tags": ["male", "middle-age"],
"displayPersona": "male, 30-40s, polite, professional",
"voice": [{
"name": "tom",
"language": "en-US",
"ttsname": "Tom",
"ttsengine": "NuanceTTS",
"displayName": "Tom"
}, {
"name": "lee",
"language": "en-AU",
"ttsname": "Lee",
"ttsengine": "NuanceTTS",
"displayName": "Lee"
}, {
"name": "felix",
"language": "fr-CA",
"ttsname": "Felix",
"ttsengine": "NuanceTTS",
"displayName": "Felix"
}, {
"name": "javier",
"language": "es-MX",
"ttsname": "Javier",
"ttsengine": "NuanceTTS",
"displayName": "Javier"
}
],
"digital": {},
"email": {},
"chat": {},
"web": {}
},
{
"id": "3",
"name": "Gabriela",
"gender": "female",
"tags": ["female", "young", "engaging"],
"displayPersona": "female, 20-30s, engaging",
"voice": [{
"name": "gabriela",
"language": "en-US",
"ttsname": "en-US-Standard-E",
"ttsengine": "GTTS",
"displayName": "Gabriela"
}, {
"name": "sheila",
"language": "en-AU",
"ttsname": "en-AU-Standard-A",
"ttsengine": "GTTS",
"displayName": "Sheila"
}, {
"name": "lili",
"language": "fr-CA",
"ttsname": "fr-CA-Standard-A",
"ttsengine": "GTTS",
"displayName": "Lili"
}
],
"digital": {},
"email": {},
"chat": {},
"web": {}
},
{
"id": "4",
"name": "Michael",
"gender": "male",
"tags": ["male", "young"],
"displayPersona": "male, 20-30s, curious, geeky",
"voice": [{
"name": "michael",
"language": "en-US",
"ttsname": "en-US-Standard-B",
"ttsengine": "GTTS",
"displayName": "Michael"
}, {
"name": "royce",
"language": "en-AU",
"ttsname": "en-AU-Standard-B",
"ttsengine": "GTTS",
"displayName": "Royce"
}, {
"name": "alexandre",
"language": "fr-CA",
"ttsname": "fr-CA-Standard-B",
"ttsengine": "GTTS",
"displayName": "Alexandre"
}
],
"digital": {},
"email": {},
"chat": {},
"web": {}
},
{
"id": "5",
"name": "Diane",
"gender": "female",
"tags": ["female", "mature"],
"displayPersona": "female, 40-50s, soothing, silky",
"voice": [{
"name": "diane",
"language": "en-US",
"ttsname": "en-US-Standard-C",
"ttsengine": "GTTS",
"displayName": "Diane"
}, {
"name": "muriel",
"language": "en-AU",
"ttsname": "en-AU-Standard-C",
"ttsengine": "GTTS",
"displayName": "Muriel"
}, {
"name": "chloe",
"language": "fr-CA",
"ttsname": "fr-CA-Standard-C",
"ttsengine": "GTTS",
"displayName": "Chloe"
}
],
"digital": {},
"email": {},
"chat": {},
"web": {}
},
{
"id": "6",
"name": "David",
"gender": "male",
"tags": ["male", "mature"],
"displayPersona": "male, 40-50s, professional, confident",
"voice": [{
"name": "david",
"language": "en-US",
"ttsname": "en-US-Standard-D",
"ttsengine": "GTTS",
"displayName": "David"
}, {
"name": "austin",
"language": "en-AU",
"ttsname": "en-AU-Standard-D",
"ttsengine": "GTTS",
"displayName": "Austin"
}, {
"name": "pierre",
"language": "fr-CA",
"ttsname": "fr-CA-Standard-D",
"ttsengine": "GTTS",
"displayName": "Pierre"
}
],
"digital": {},
"email": {},
"chat": {},
"web": {}
}
]</source>
===Update Designer flowsettings.json===

*Enable the persona <code>feature</code> flag in the '''flowsettings.json''' override file.
<source>"features": {
"persona": true</source>
===Update application settings===
Perform the following steps to enable the persona in the required Designer application:

#Open the required Designer application and navigate to the '''Settings''' tab.
#In '''Application Settings''', select the '''Enable''' '''Persona''' checkbox in the '''Persona''' tab.
#Re-publish the application and create a new build.
|Status=No
}}
}}