vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Register users Org2 MSP Admin org2admin org2adminpw admin 
 Peer identity peer2 peer2pw peer 







 Creating the peer organization MSP 

Now that we have created the peer's CA and used it to register our organization identities, we need to create a formal definition of the peer's organization, which is known as the Membership Services Provider (MSP) definition. Many peers can belong to an organization. You do not need to create a new organization every time you create a peer. Because this is the first time that we go through the tutorial, we will create the MSP definition for this organization. During the process of creating the MSP, we are going to generate certificates for the org2admin identity and add them to our Wallet.



1. Navigate to the Organizations tab in the left navigation and click Create MSP definition.
2. On the first panel, enter Org2 MSP as the organization MSP display name and org2msp and as the MSP ID. If you plan to specify an MSP other than org2msp, make sure to review the guidelines for MSP names in the tooltip. Click Next.
3. On the Root Certificate Authority details panel, specify the CA you used to register the identities for this organization. If this is your first time through this tutorial, you should only see one: Org2 CA. The CA root certificate and TLS CA root certificate are displayed. Click Next.
4. On the Admin certificates panel, select the enroll ID you created for your organization admin from the drop-down list, org2admin, and enter its associated secret, org2adminpw. Then, give this identity a display name, Org2 MSP Admin. Note: the default display name for this identity is the name of your MSP and the word "Admin". If you select a different name for your MSP, that will be reflected in the default.
5. Click the Generate button to enroll this identity as the admin of your organization and export the identity to the Wallet, where it will be used when creating the peer and creating channels.
6. Click Export to export the admin certificates to your file system.
To synthesize text to speech with the HTTP REST interface of the IBM Watson® Text to Speech service, you call the GET or POST /v1/synthesize method. You specify the text that is to be synthesized and the voice and format for the spoken audio. You can also specify a custom model that is to be used with the request.

For more information about the HTTP interface, see the [API & SDK reference](https://cloud.ibm.com/apidocs/text-to-speech).



 Synthesizing text to audio 

To synthesize text to audio, you call one of the two versions of the service's /v1/synthesize method:



* The GET /v1/synthesize method accepts the text that is to be synthesized as a required text query parameter. The maximum size of the request is 8 KB, which includes the input text, any SSML that you specify, and the URL and headers.
* The POST /v1/synthesize method accepts the text that is to be synthesized as a JSON construct in the required body of the request. The maximum size of the request is 8 KB for the URL and headers, and 5 KB for the input text that is sent in the body of the request. The 5 KB limit includes any SSML that you specify.



The two versions of the /v1/synthesize method have the following parameters in common:

accept (query parameter, optional string)
: Specifies the requested audio format, or MIME type, in which the service is to return the audio. You can also specify this value with the HTTP Accept request header. URL-encode the argument to the accept query parameter. By default, the service returns the audio in the format audio/ogg;codecs=opus. For more information, see [Using audio formats](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-audio-formats).

The Ogg audio format is not supported with the Safari browser. If you are using the the Text to Speech service with the Safari browser, you must specify a different format in which you want the service to return the audio.
The advantage of an MZR is that it provides consistent cloud services across the different zones, better resiliency, availability, higher interconnect speed between data centers for cloud platforms, and infrastructure services such as IBM Cloud® Object Storage, and IBM Cloud load balancers. These features can be critical to your applications. Deploying the application in an MZR rather than a single zone can increase the availability from 3 9’s to 5 9’s when deployed over three zones.



 PODs 

IBM Cloud data centers are also based on POD architecture where each data center can have more than one POD, depending on on-demand buildout. Each POD consists of racks, servers, networks, and storage, along with backup power generators. Placing the application servers across PODs further improves the availability.

See [Locations for resource deployment](https://cloud.ibm.com/docs/overview?topic=overview-locationsmzr-table) for a complete list of regions and data centers.







 Bare metal, virtual server deployment model for Classic Infrastructure 

With IBM Cloud, you can control the exact compute resource on which you want to deploy your workload or application. Whether it is bare metal for dedicated resource and better performance, or virtual for deployment speed, agility, and cost, it is important to understand the network connectivity from the server to the top-of-rack (TOR), and how it plays into redundancy is critical.



 Linking your bare metal server 

For bare metal servers, you can order a server as a single link or redundant link. If the workload doesn’t have any redundancy that is built into its application, it is best to order a redundant link for added link protection.

If your workload already has redundancy built into the application, whether it is through clustering or replication, you might be considering a single link rather than a redundant link to reduce costs. Keep in mind that having a redundant link is still a better option because it eliminates the link as the single point of failure (SPOF) and provides more bandwidth to the server.

Note: Some of the older data centers provide only single link connection. In this case, make sure that your workload has redundancy that is built into the application. SEA01, for example is a single 1G connection.
About Microsoft SQL on VPC 

IBM Cloud VPC now offers a bundle of Windows Server 2019 Standard and SQL Server 2019 Web edition. Customers may choose to either use the bundle offering with a pre-configured installation or use the Bring Your Own License (BYOL) and Do It Yourself (DIY) build process after you have ordered a virtual server instance in your VPC. Customers should determine which approach matches their requirements and proceed accordingly.

This documentation provides guidance on how to deploy, configure, and tune the BYOL components, including virtual server instances, storage volumes, networking, and security

This documentation does not cover SQL Server Integration Services (SSIS), Reporting Services (SSRS), or Analysis Services (SSAS).



 About the Microsoft SQL on VPC deployment patterns 

This guide is focused on getting an optimal performance and cost balance for Microsoft SQL Server deployments on IBM Cloud VPC virtual servers. There is typically a trade-off between optimizing for costs and optimizing for performance, and if your workload is very demanding, you must evaluate these guidelines while considering your performance requirements.

When selecting your IBM Cloud for VPC virtual server to host your SQL databases, an understanding of the database workload is required:



* For migration of an existing environment, collect a performance baseline of your existing database instance to determine your virtual server requirements.
* For new workloads, work with your application vendor to understand the SQL database requirements.



It is important to remember that an advantage of cloud-based solutions is the ability to resize after initial deployment. For more information, refer to [Resizing a virtual server instance](https://cloud.ibm.com/docs/vpc?topic=vpc-resizing-an-instance). For information on collecting a performance baseline, refer to [Creating a baseline](https://cloud.ibm.com/docs/vlans?topic=vlans-mssql-baseline).

This documentation focuses on three deployment patterns in IBM Cloud VPC leveraging Availability Zones (AZ) and Multi Zone Regions (MZR):



* Single AZ deployment pattern - This pattern is suitable for development or test databases that do not require high availability or rapid disaster recovery.
NSX-V to NSX-T lift-and-shift migration approach 

VMware NSX-V to VMware NSX-T™ migration in IBM Cloud® is done by following the VMware® lift-and-shift migration model. In this model, you deploy a new NSX-T infrastructure on new server hardware so you can benefit from the Cloud consumption model.

In IBM Cloud, you need to deploy a new vCenter Server® with NSX-T instance, which then runs in parallel with the existing vCenter Server with NSX-V instance. The NSX-T architecture is different than the NSX-V architecture, though they share similar concepts for overlay networking, distributed routing, and firewalling.

Zoom

![NSX-V to NSX-T lift–and-shift migration approach](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/v2t-diagrams-lift-and-shift.svg)

Figure 1. NSX-V to NSX-T lift–and-shift migration approach



1. Your existing NSX-V based instance was deployed previously and it hosts the current workloads and NSX-V network configurations. Before you start the migration, you need to have a thorough understanding of the environment, the workloads that are deployed on it, and the NSX-V and underlay network configurations.
2. Before you deploy a new NSX-T based vCenter Server target, analyze your capacity needs. Optimize and size your new hosts and clusters by using the latest hardware options available in IBM Cloud. Check the latest options in the VMware Solutions console, or contact your local Sales representative for more details.
3. You can deploy the new vCenter Server with NSX-T instance in new VLANs and a new pod, or you can use existing VLANs. 25GE NICs might not be available on the same pod.
For more information about the data centers in which VMware Solutions can be deployed, see [IBM Cloud data center availability](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_planningvc_planning-dc-availability).



The focus of the IBM Cloud for VMware Regulated Workloads DR design has the following specifications.



* A design to deliver against the two key requirements:



* Establish an alternative site in a different region for failover of workloads if a failure occurs in the primary site.
* Failover of the workloads that meets customer’s Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) application requirements.



* A design that defines the recovery of the infrastructure and management components in the alternative site.
* A design that allows flexibility in the recovery of the workloads, but does not define how the workloads are recovered. This approach allows maximum flexibility to meet customer’s RTO/RPO application requirements.

Notes



* If you select single campus MZR or data center, the placement of the KMIP for VMware and Hyper Protect Crypto Services is not local to the VMware Regulated Workloads instance. Latency between the services and the instance is not an issue due to when the keys are requested that is, on initial encryption, rekey requests, and ESXi server restarts.
* Ensure that you know the location of all service components and ensure that their required regulatory compliance can be achieved.







 Concept 

The IBM Cloud for VMware Regulated Workloads dual region design concept is based on the automated deployment of two IBM Cloud for VMware Regulated Workloads instances, each deployed into a different IBM Cloud multizone region. The use of different multizone regions enables DR due to:



* Colocation of services - KMIP™ for VMware and Hyper Protect Crypto Services are hosted in multizone regions.
* Geographical distance - the risk that the same physical event impacts both multizone regions is low.
* Resiliency - logical services in each region are independent, such that a failure in one service does not impact the service in the other region.



Hyper Protect Crypto Services is not available in the London multizone region.
* Action: Visual Recognition to check uploaded file before import of document into ERP
* For example, check that uploaded image is:



* A contract document
* The correct contract required
* Has a signature in the required position of the form





3. ABAP with SAP GUI + ABAP SDK for IBM Watson



* Action: Visual Recognition and Language Translation of document that is imported into ERP
* For example, upload contract document in a different language:
* Convert to English
* Extract specific data points
* Triggers integrated business process (Finance, Planning, and other processes) or RPA flow





Resulting in a vendor comparison by global Category Managers which:



* Reduces low-quality data entry
* Compares Payment Term Objectives
* Investigates payment punctuality of Invoice Payment Days above Term
* Starts execution of automated Next Best Action workflow routing







 Available IBM Watson APIs with the ABAP SDK 

Full [documentation for IBM Watson Developer Services](https://cloud.ibm.com/developer/watson/documentation) is available.

The ABAP SDK for IBM Watson provides for the following IBM Watson Developer Services:



* Compare and Comply
* Discovery
* Language Translator
* Natural Language Classifier
* Natural Language Understanding
* Personality Insights
* Speech to Text
* Text to Speech
* Tone Analyzer
* Visual Recognition
* Watson Assistant







 Getting started with the ABAP SDK for IBM Watson 

The four main steps to getting started are:



1. Import the ABAP SDK by using abapGit. Use Online Mode with clone of GitHub Repository or Offline Mode with .zip download from GitHub, and import into your ABAP runtime
2. Create IBM Cloud account. Start with the free “Lite” IBM Watson Developer Services on cloud.ibm.com, obtain service instance credentials for use in ABAP SDK
3. Use Sample Code examples. To begin innovation initiatives combined with any SAP Application, while you are following SAP’s ABAP coding standards
4. Begin developing business-led value. Create your Intelligent Enterprise with SAP, combining SAP business application data with insights from IBM Watson
Resource groups are a way for you to organize your account resources into customizable groupings.
* Click on Create.
* Wait until the project status changes to Active.



3. Switch to the Cloud Shell session that you started earlier and use it in this tutorial when you are asked to run CLI commands.
4. Create a shell variable with the project name and resource group name

PROJECT_NAME=YourProjectName
RESOURCE_GROUP_NAME=YourResourceGroupName
5. Target the resource group where you created your project.

ibmcloud target -g $RESOURCE_GROUP_NAME
6. Make the command line tooling point to your project

ibmcloud code-engine project select --name $PROJECT_NAME







 Step 3: Deploy the frontend and backend apps as Code Engine applications 

Code Engine Applications run your code to serve HTTP requests, automatically scale up and back down to zero, and offer traffic routing to multiple revisions. In this section, you will deploy your frontend and backend applications to the Code Engine project. The frontend web application will allow users to upload text files, while the backend application will write the file to IBM Cloud Object Storage.

We've already built images for the two applications and pushed them to the public Container Registry. You will use these pre-built container images to deploy the respective applications. Creation of your own applications will be covered in a later step.



 Deploy a frontend application 



1. To deploy a new Code Engine application, run the following command; providing a service name frontend and the pre-built container image as a parameter to --image flag.

ibmcloud code-engine application create --name frontend --image icr.io/solution-tutorials/tutorial-text-analysis-code-engine-frontend

After running this command, you should see some output with a URL to your application. It should look something like: https://frontend.305atabsd0w.us-south.codeengine.appdomain.cloud. Make note of this application URL for the next step.
If you prefer to use a Terraform template to generate these resources, you can use the template that is available here: [https://github.com/IBM-Cloud/vpc-tutorials/tree/master/vpc-lamp](https://github.com/IBM-Cloud/vpc-tutorials/tree/master/vpc-lamp) and follow the instructions in the README.md. This template can also be used in [Schematics](https://cloud.ibm.com/schematics/overview).



1. From the [IBM Cloud Console](https://cloud.ibm.com/), launch the [IBM Cloud Shell](https://cloud.ibm.com/shell).
2. You are automatically logged into one of the IBM Cloud regions, you can switch to a different region if desired by running the following command:

ibmcloud target -r <region-name> -g <resource-group>





 Create SSH Key(s) 



1. In VPC an SSH key is used for administrator access to a VSI instead of a password. Create an SSH Key by running the following command and accept the defaults when prompted. For more information on SSH keys, see the docs [SSH Keys](https://cloud.ibm.com/docs/vpc?topic=vpc-ssh-keys).

ssh-keygen -t rsa -b 4096

The above command generates two files inside of the /.ssh directory: id_rsa and id_rsa.pub. Your Cloud Shell session is [short lived](https://cloud.ibm.com/docs/cloud-shell?topic=cloud-shell-shell-uimulti-shell), any files you create inside of IBM Cloud Shell should be saved in a safe location for future re-use. There is a download and upload file option in Cloud Shell on the upper right section of the screen.

If you have an existing SSH key that you would like to re-use, you can upload it to your Cloud Shell session instead.
2.
For example they provide a free appetizer at the chef's restaurant and an extra incentive to buy the ingredients for the demonstrated meal (for example, $20 off $150 cart).

The solution is made up of the following primary components.



1. INVENTORY ANALYSIS: the in-store events (recipes, ingredient lists, and product locations) are tailored to market the slow-moving inventory.
2. LOYALTY MOBILE APP provides targeted marketing with digital coupons, shopping lists, product inventory (prices, availability) on a store map, and social sharing.
3. SOCIAL MEDIA ANALYTICS provides personalization by detecting customers’ preferences in terms of trends: cuisines, chefs, and ingredients. The analytics connect regional trends with an individual’s Twitter, Pinterest, and Instagram activity.
4. DEVELOPER-FRIENDLY TOOLS accelerate roll-out of features and bug fixes.



Back-end inventory systems for product inventory, store replenishment, and product forecasting have a wealth of information, but modern analytics can unlock new insights about how to better move high-end products. By using a combination of IBM Cloudant and IBM Streaming Analytics, the CMO can find the sweet spot of ingredients to match to custom in-store events.

IBM® Event Streams for IBM Cloud® acts as the just-in-time events platform to bring in the rapidly changing information from the inventory systems to IBM Streaming Analytics.

Social media analytics with Watson Discovery (personality and tone insights) also feed in trends to the inventory analysis to improve product forecasting.

The loyalty mobile app provides detailed personalization information, especially when customers use its social sharing features, such as posting recipes.

In addition to the mobile app, the Developers are busy with building and maintaining the existing loyalty app that’s tied to traditional checkout coupons. In short, they need to focus on coding instead of managing the infrastructure. Thus, they chose Red Hat OpenShift on IBM Cloud because IBM simplifies infrastructure management.



* Managing Kubernetes master, IaaS, and operational components, such as Ingress and storage
* Monitoring health and recovery for worker nodes
* Providing global compute, so Developers aren't responsible for infrastructure setup in data centers



Compute, storage, and event management that run in public cloud with access to back-end ERP systems
We recommend producers to produce to local topics only, hence they should not require changes when they switch between clusters.





 Consumers 

Consumers should subscribe to and consume from both the local and remote topics. This can be done with one wild-carded subscription. For example, to consume from both accounting.invoice and accounting.invoice.<ALIAS>, use the subscription to accounting.invoice..

When you consume both local and remote topics, check if the application requires strict ordering. In such a case, remote topics are to be fully consumed first before you start to consume from local topics. This way messages are processed in the order that they were produced.





 Consumer offsets 

While consumer groups offsets are replicated between clusters, they must be explicitly used by consumers to reset their position when they switch cluster.

The RemoteClusterUtils package allows to easily make these changes. Such logic is demonstrated in [ConsumerRunnable.java](https://github.ibm.com/messagehub/event-streams-samples/blob/mm2/kafka-java-console-sample/src/main/java/com/eventstreams/samples/ConsumerRunnable.javaL68-L119).







 Monitoring mirroring 

You can monitor mirroring by using IBM Cloud Monitoring. To enable monitoring, see [Monitoring Event Streams metrics](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-metrics). The Monitoring dashboard is available on the target cluster.

The Event Streams Mirroring dashboard exposes the following metrics:



* Mirroring throughput: The bytes per second of mirroring throughput from the source Event Streams instance. This is useful to see whether mirroring is active and for capacity planning.
* Mirroring latency: The per-topic mirroring latency in second from the source Event Streams instance. This is useful to determine how far behind a topic on the target cluster is.



Data that is produced within the latency window might not be present on the target cluster yet and still might be lost if a disaster happens on the source cluster.
* Total number of vCPU cores = 2 Cores x the number of concurrent users
* Total memory size = 8 GB x the number of concurrent users
* Total disk size = 200 GB x the number of concurrent users



Additional Storage option are also available at t-shirt size (100GB/500GB/1000GB/2000GB)

The specific configuration of VM (e.g. vCPU cores, memory size, disk size) is flexible to change to meet your requirement. However the total concurrent resource consumption should be within total resource limitation.





 How to order IBM Cloud for Education Applications Lab 



1. Log in to IBM Cloud.
2. Select "IBM Cloud for Education" tile.
3. Choose the plan.
4. Input "The number of concurrent user authorized" based on capacity planning.
5. Choose the capacity of persistent storage for your institution.







 Next steps 

Activities to complete "Pending for Provisioning":

Our support engineer will reach out to client through email to confirm the authentication method to prepare client’s access to Applications Lab. Following is the activities included to complete the provision request.



1. Setup authentication method: client can request to integrate with client’s LDAP/Directory Server for faculties and students authentication.
2. Configure the access control policy for users.



The duration of the setup usually will take up to few hours for non-LDAP integration and for LDAP integration it may take up to a few days.