vania-janet/multiturn-rag-retrieval-data huggingface dataset:
"key2": "value2"
}
}
}
}

When generating a CDR report, the custom data is included in the injected_custom_data field. For example, in the following CDR report, the key1 and key2 are added to the injected_custom_data field.

{
"payload": {
...
"injected_custom_data": {
"key1": "value1",
"key2": "value2"
}
...
}
}



 Merging CDR data 

During a call, if the cdr_custom_data context variable is received multiple times, the data is merged in the injected_custom_data field.

In the first call, values for key1 and key2 are defined.

"context": {
"integrations": {
"voice_telephony": {
"cdr_custom_data": {
"key1": "value1",
"key2": "value2"
}
}
}
}

In the second call, values for key1 and key3 are defined.

"context": {
"integrations": {
"voice_telephony": {
"cdr_custom_data": {
"key1": "value11",
"key3": "valu3"
}
}
}
}

After these calls, the following code example shows how the custom CDR data is merged in the injected_custom_data field.

{
"payload": {
...
"injected_custom_data": {
"key1": "value11",
"key2": "value2",
"key3": "value3"
}
...
}
}





 Removing custom CDR data 

To remove a key from the CDR custom data, set the cdr_custom_data context variable with that key set to "".
(https://cloud.ibm.com/docs-content/v1/content/ca9232b3702768f24bb897f48f10778fcda28718/watson-assistant/images/zd-products-menu.png)
6. Click your profile, and then select Check Connection.

![Screen capture of the Zendesk user interface to show where the profile is located.](https://cloud.ibm.com/docs-content/v1/content/ca9232b3702768f24bb897f48f10778fcda28718/watson-assistant/images/zd-profile-menu.png)
7. Keep this open for the Connect Zendesk to your assistant step.

![Screen capture of the connection dialog.](https://cloud.ibm.com/docs-content/v1/content/ca9232b3702768f24bb897f48f10778fcda28718/watson-assistant/images/zd-account-key.png)



You also need to decide whether to enable security for Zendesk after setup. More info at [Securing the transfer to Zendesk](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-deploy-zendeskdeploy-zendesk-secure).





 Setting up the Zendesk service desk connection 

In your Watson Assistant install:



1. Go to the Integrations page by clicking the integrations icon (![Integrations icon](https://cloud.ibm.com/docs-content/v1/content/ca9232b3702768f24bb897f48f10778fcda28718/watson-assistant/images/integrations-icon.png)) in the left menu.
Parameter Usage Type Terraform argument Description 

 blind_connection optional, updatable, Default: false Boolean blind_connection Set to true to instruct Continuous Delivery to ignore the configuration validation of this integration. Also, set to true if the SonarQube server is not addressable on the public internet. 
 dashboard_url required, updatable String server_url The URL of the SonarQube server dashboars for this tool integration. In the graphical UI, the browser goes to this dashboard when you click the SonarQube tool integration card. 
 name required, updatable String name The name of this tool integration. 
 user_login optional, updatable String user_login The user ID for authenticating with the SonarQube server. 
 user_password optional, updatable Password user_password The password or token to authenticate with the SonarQube server. You can use a toolchain secrets reference for this parameter. For more information about secrets references, see [Protecting your sensitive data in Continuous Delivery](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-cd_data_securitycd_secure_credentials). 







 Learn more about SonarQube 

To learn more about SonarQube, see [Integrate your SonarQube analysis into your toolchain](https://www.ibm.com/blogs/cloud-archive/2017/06/integrate-sonarqube-analysis-into-your-toolchain/).
Just as it was before IAM integration, the connection stays connected until the application disconnects or the connection is terminated due to other reasons.

curl -k -X POST 
--header "Content-Type: application/x-www-form-urlencoded" 
--header "Accept: application/json" 
--data-urlencode "grant_type=urn:ibm:params:oauth:grant-type:apikey" 
--data-urlencode "apikey=<apikey>" 
"https://iam.cloud.ibm.com/identity/token"

An access token identifies an IBMid user or a service ID to the database. The database server verifies the validity of the access token before accepting it. This is the best method if the application needs to connect to more than one database service instance or other IBM Cloud service instances because it minimizes the communication to the IAM service to validate the access token.





 API key 

Multiple API keys can be created for each IBMid user or service ID. Each API key is typically created for a single application. It allows the application to connect to the database service instance as long as the owning IBMid or service ID is added as a user to the same database service instance. The API key has the same authorities and permissions within the database as the owning IBMid or service ID. If an application should no longer be allowed to connect to the database, the corresponding API key can be removed. This method of authentication requires fewer changes in the application than using an access token as it requires no direct interaction with the IAM service. For more information about creating and managing API keys, see: [Managing user API keys](https://cloud.ibm.com/docs/account?topic=account-userapikey).





 IBMid/password 

The IBMid/password can be used to log in to the console and can also be used within the application in the same ways that a user ID/password is allowed. The exception occurs when the IBMid is federated because a redirection to your organization’s login page cannot be done.
Just as it was before IAM integration, the connection stays connected until the application disconnects or the connection is terminated due to other reasons.

curl -k -X POST 
--header "Content-Type: application/x-www-form-urlencoded" 
--header "Accept: application/json" 
--data-urlencode "grant_type=urn:ibm:params:oauth:grant-type:apikey" 
--data-urlencode "apikey=<apikey>" 
"https://iam.cloud.ibm.com/identity/token"

An access token identifies an IBMid user or a service ID to the database. The database server verifies the validity of the access token before accepting it. This is the best method if the application needs to connect to more than one database service instance or other IBM Cloud service instances because it minimizes the communication to the IAM service to validate the access token.





 API key 

Multiple API keys can be created for each IBMid user or service ID. Each API key is typically created for a single application. It allows the application to connect to the database service instance as long as the owning IBMid or service ID is added as a user to the same database service instance. The API key has the same authorities and permissions within the database as the owning IBMid or service ID. If an application should no longer be allowed to connect to the database, the corresponding API key can be removed. This method of authentication requires less changes in the application than using an access token as it requires no direct interaction with the IAM service. For more information about creating and managing API keys, see: [Managing user API keys](https://cloud.ibm.com/docs/account?topic=account-userapikey).





 IBMid/password 

The IBMid/password can be used to log in to the console and can also be used within the application in the same ways that a user ID/password is allowed. The exception occurs when the IBMid is federated because a redirection to your organization’s login page cannot be done.
IBM Key Protect 

Use [Key Protect](https://cloud.ibm.com/catalog/services/key-protect) to securely store and apply secrets like API keys, Image Signature, or HashiCorp Vault credentials that are part of your toolchain. You must create a Key Protect Service Instance before you proceed further. If you already created a Key Protect Service Instance, you can link the same in this step.

Zoom

![Key Protect](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops_set-up_key_protect_mgr.png)

Figure 8. Key protect



* Name: Name of Key Protect instance created by the toolchain. This key protect instance can be accessed by this name during various stages of the toolchain setup.
* Region: Region in which the Key Protect service is located.
* Resource Group: Resource Group that the Key Protect service belongs.
* Service name: Key Protect service name.



To comply with best practices for using HashiCorp Vault, this template includes a Key Protect tool integration to securely manage the HashiCorp Vault Role ID and Secret ID. By storing these HashiCorp Vault secrets in Key Protect as a prerequisite for users to create toolchains, you protect access to HashiCorp Vault, which is the default secrets repo for most consumers.





 IBM Secrets Manager 

Use [Secrets Manager](https://cloud.ibm.com/catalog/services/secrets-manager) to securely store and apply secrets like API keys, Image Signature, or Hashicorp Vault credentials that are part of your toolchain. You must create a Secrets Manager Service Instance before you proceed further. If you already created a Secrets Manager Service Instance as prerequisite, you can link the same in this step.

Zoom

!
* Public and Private Networking - Databases for MySQL is integrated with [Service Endpoints](https://cloud.ibm.com/docs/databases-for-mysql?topic=cloud-databases-service-endpoints). You can select whether to use connections over the public network, the IBM Cloud internal network, or both.
* Dedicated Cores - Allocating dedicated cores to your deployment introduces hypervisor-level isolation to your database instance, by using isolated virtual machines to ensure that your data processing remains separated from other customers. It also provides a minimum number of CPUs to your deployment. Deployments with dedicated cores in the same Resource Group and IBM Cloud Region might share a virtual machine.
* Do not grant the [PROCESS](https://dev.mysql.com/doc/refman/5.7/en/privileges-provided.htmlpriv_process) or [SUPER](https://dev.mysql.com/doc/refman/5.7/en/privileges-provided.htmlpriv_super) privilege to nonadministrative users. mysqld reserves an extra connection for users who have the SUPER privilege so that a MySQL root user can log in and check server activity even if all normal connections are in use.
* The [SUPER](https://dev.mysql.com/doc/refman/5.7/en/privileges-provided.htmlpriv_super) privilege can be used to terminate client connections, change server operation by changing the value of system variables, and control replication servers. For more information, see MySQL's [Making MySQL Secure Against Attackers](https://dev.mysql.com/doc/refman/5.7/en/security-against-attack.html) documentation.







 Data Resilience 



* [Backups](https://cloud.ibm.com/docs/databases-for-mysql?topic=cloud-databases-dashboard-backups) are included in the service.
You can also make direct calls to the [Key Protect APIs](https://cloud.ibm.com/apidocs/key-protect), also through the Key Protect on Satellite endpoint. For more information about how to obtain the Key Protect on Satellite endpoint from GhoST, check out [Obtaining the Key Protect endpoint](https://cloud.ibm.com/docs/key-protect?topic=key-protect-satellite-aboutsatellite-about-before-begin-endpoint). Note that keys you create using the CLI or API will not show up in the Key Protect UI.
* All of the metrics that are typically available through IBM Cloud Monitoring and are not available in the initial Key Protect on Satellite release, but will be added in a future release. Because Key Protect does not have the ability to receive logs from an HSM, the security monitoring of the HSMs are the responsibility of the owner of the HSM. To receive auditing logs, you must create an IBM Cloud Activity Tracker instance before provisioning Key Protect on Satellite using the process described in [Using IBM Cloud Activity Tracker with Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-satellite-aboutsatellite-about-before-begin-activity). Check out [Responsibilities](https://cloud.ibm.com/docs/key-protect?topic=key-protect-satellite-aboutsatellite-about-before-begin-responsibilities) for more information about the responsibilities taken on by IBM and those you must cover.
* End-to-end key lifecycle [service integrations](https://cloud.ibm.com/docs/key-protect?topic=key-protect-integrate-cos) and [sync of associated resources](https://cloud.ibm.com/docs/key-protect?topic=key-protect-sync-associated-resources) is not currently supported in Key Protect on Satellite.
Click Continue.







 Step 3: Add optional tool integrations 

You can add the IBM Cloud® DevOps Insights tool integration to your toolchain without any additional configuration.

[DevOps Insights](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-di_working) is included in the created toolchain. You do not need to provide any configuration steps for DevOps Insights. The continuous integration pipeline automatically uses the DevOps Insights instance that is included in the toolchain. DevOps Insights aggregates code, test, build, and deployment data to provide visibility into the velocity and quality of all of your teams and releases.

Click Continue.





 Step 4: Complete the toolchain setup 

On the Summary page, click Create toolchain. Several steps run automatically to set up your toolchain.

You can configure the individual toolchain integrations after the pipeline is created.

Zoom

![Code Engine secure app toolchain Summary](https://cloud.ibm.com/docs-content/v1/content/efbf7b33e3aca029f69f9244bced9dd4d8acb848/apps/includes/ContinuousDelivery/includes/ContinuousDelivery/images/code_engine_summary.png)

Figure 6. Code Engine secure app toolchain summary





 Step 5: Explore your new toolchain 

After you create your toolchain, it shows each of the tool integrations that are part of the toolchain in a diagram.



 Explore the pipelines 

You can explore the pipelines to understand the toolchain flow and the different operations that run within each pipeline. The toolchain that you created contains the following pipelines:



* Pull request pipeline: Runs when a developer merges changes from their development branch to the master branch, or to any other branch in the repo. The pull request pipeline runs the Unit Test and Static Scans on the Application Source Code.
* Continuous integration pipeline: Runs when you merge a change into the master branch of the Application Source Code repo.
As a result of the vCenter and NSX integration, the HCX Manager appliance is assigned a private portable IP address on the management VLAN.



Table 4. HCX Manager

 Component Configuration 

 CPU 4 vCPU 
 RAM 12 GB 
 Disk 60 GB VMDK resident on shared storage 



Additionally, it is configured to access vCenter and NSX with a specific user. It is important to note that the HCX Manager’s IP address is the same IP address that is used in the NSX edge for load balancing.

After the HCX Manager cloud component is deployed and configured, the source components create a connection to the HCX Manager through the VIP addresses configured in the NSX ESG. After this connection is made, the HCX-IX Interconnect Appliance and HCX WAN Optimizer appliances are deployed within the IBM Cloud.





 HCX-IX Interconnect Appliance 

A virtual appliance is deployed after a connection is established from the source to the target cloud. This appliance is the HCX-IX Interconnect Appliance (CGW) and is used to maintain a secure channel between vSphere environment that is designated as the source and the IBM Cloud.

The following table shows the sizing specification of the CGW appliance that is deployed within the IBM Cloud.



Table 5. HCX-IX Interconnect Appliance deployment

 Component Configuration 

 CPU 8 vCPU 
 RAM 3 GB 
 Disk 2 GB VMDK resident on shared storage 



This HCX-IX Interconnect Appliance is deployed and configured to be on the management VLAN (Private Portable Subnet) and on the vMotion VLAN (Private Portable Subnet) of the IBM Cloud for VMware Solutions deployment. Additionally, another interface is configured on the Public VLAN (Public Portable) for connections that are made over the public internet. Public access is not required if a direct connection exists (private connection in place). The last connection that is associated with the HCX-IX Interconnect Appliance is a logical switch that is created and configured upon site pairing.





 HCX WAN Optimizer 

The second component that is deployed is the WAN Optimization appliance.
* Move the BRMS data back to the production VM before shutting down the backup VM
* Remove the cloned volumes.



It also allows you to quickly create an intermediate snap-shot then a volumes-clone before entering the long-running volume detach or attach phase. You have the ability to pause the process immediately before attaching volumes.





 How do you set up private networks between Intel® Virtual Servers (x86) and Power Systems Virtual Servers? 

See the tutorial on [IBM Power Systems Virtual Server integration with x86-based workloads](https://cloud.ibm.com/media/docs/downloads/power-iaas-tutorials/PowerVS_and_x86_Integration_Tutorial_v1.pdf).





 How do you set up customer site access to a private network by using VPN? 

For a complete tutorial on site-to-site Virtual Private Network (VPN) connectivity from an on-premise environment to Power Systems Virtual Server, see [IBM Power Virtual Server Virtual Private Network Connectivity](https://cloud.ibm.com/media/docs/downloads/power-iaas-tutorials/PowerVS_VPN_Tutorial_v1.pdf). For more information on VPN, see [Managing VPN connections](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-VPN-connections).





 What firewall options are there around VPN connectivity? 

You must set your own firewall in your IBM Cloud account.





 How do you connect a server instance between two data centers (DAL13 to WDC04)? 

You can use IBM Cloud Connect to connect two data centers. IBM Cloud Connect is a software-defined network interconnect service that brings secure connectivity to client locations around the world. For more information, see [Connecting Power Systems Virtual Server instances and networks](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-connecting-networks).

IBM Cloud Connect is only available to IBM clients within the US.





 How is network bandwidth billed? 

IBM Cloud Classic environment: Inbound bandwidth is unlimited and not charged.
BIG-IP feature enhancement for HPCS integration is being worked on.







 Step 7: Import server-side intermediate certificates to BIG-IP 

For each server certificate that you have, complete the following actions:



1. In the console, go to System > Certificate Management > Traffic Certificate Management.
2. Click Import.
3. Select Certificate from the Import Type.
4. In the Certificate Name field, enter a name for your certificate.
5. Either upload your certificate or paste your certificate under the option Certificate Source.
6. Click Import.



BIG-IP feature enhancement for HPCS integration is being worked on.





 Step 8: Configure ciphers 

In this step, you create a cipher policy and group to limit the ciphers that are able to be used for a secure connection.

For more information on TLS requirements and acceptable cipher suites, see [Data encryption in transit](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-encryption-in-transit).



 Create a cipher policy 



1. In the BIG-IP console, go to Local Traffic > Ciphers > Rules.
2. Click Create.
3. Set the following options:



* Name: Name that you want to user for this policy
* Cipher Suites: ECDHE-ECDSA-CHACHA20-POLY1305-SHA256:ECDHE-RSA-CHACHA20-POLY1305-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:TLSV1_3



4. Click Finished.







 Create a cipher group 



1. In the BIG-IP console, go to Local Traffic > Ciphers > Groups.
2. Click Create.
3. Set the following options:
[Kubernetes secure app deployment target details for Canary](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/ds_kub_setup_dep_target_canary.png)

Figure 8. Kubernetes secure app Canary deployment target details





 Step 3: Add optional tool integrations 

You can add the IBM Cloud® DevOps Insights tool integration to your toolchain without any additional configuration.

[DevOps Insights](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-di_working) is included in the created toolchain. You do not need to provide any configuration steps for DevOps Insights. The continuous integration pipeline automatically uses the DevOps Insights instance that is included in the toolchain. DevOps Insights aggregates code, test, build, and deployment data to provide visibility into the velocity and quality of all of your teams and releases.

Click Continue.





 Step 4: Complete the toolchain setup 

On the Summary page, click Create. Several steps run automatically to set up your toolchain.

You can configure the individual toolchain integrations after the pipeline is created.

Zoom

![Kubernetes secure app toolchain Summary](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/ds_kub_setup_summary.png)

Figure 9. Kubernetes secure app toolchain summary





 Step 5: Explore your new toolchain 

After you create your toolchain, it shows each of the tool integrations that are part of the toolchain in a diagram.



 Explore the pipelines 

You can explore the pipelines to understand the toolchain flow and the different operations that run within each pipeline. The toolchain that you just created contains three pipelines:
The Jenkins tool integration supports the following configuration parameters that you can use with the [Toolchain HTTP API and SDKs](https://cloud.ibm.com/apidocs/toolchain) when you [create](https://cloud.ibm.com/apidocs/toolchaincreate-tool), [read](https://cloud.ibm.com/apidocs/toolchainget-tool-by-id), and [update](https://cloud.ibm.com/apidocs/toolchainupdate-tool) tool integrations.

You must specify the tool_type_id property in the request body with the jenkins value.



Table 1. Jenkins tool integration parameters

 Parameter Usage Type Terraform argument Description 

 api_token optional, updatable Password api_token The API token to use for Jenkins REST API calls so that DevOps Insights can collect data from Jenkins. You can find the API token on the Configuration page of your Jenkins instance. You can use a toolchain secret reference for this parameter. For more information about secret references, see [Protecting your sensitive data in Continuous Delivery](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-cd_data_securitycd_secure_credentials). 
 api_user_name optional, updatable String api_user_name The username to use with the Jenkins server's API token, which is required so that DevOps Insights can collect data from Jenkins. You can find your API username on the Configuration page of your Jenkins instance. 
 dashboard_url required, updatable String dashboard_url The URL of the Jenkins server dashboard for this tool integration. In the graphical UI, the browser goes to this dashboard when you click the Jenkins tool integration card. 
 name required, updatable String name The name of this tool integration. 
 webhook_url optional, updatable String webhook_url The webhook to use in your Jenkins jobs to send notifications to other tools in your toolchain. 







 Learn more about Jenkins