vania-janet/multiturn-rag-retrieval-data huggingface dataset:
EP11 is designed for users that are seeking support for open standards and enhanced security. The [EP11 library](https://www.ibm.com/security/cryptocards/pciecc4/library) offers a wide variety of general-purpose cryptographic functions and provides an interface that is similar to the PKCS #11 API. Existing applications that use PKCS #11 can benefit from enhanced security because the applications can be migrated easily to meet the EP11 requirements.

Hyper Protect Crypto Services leverages [gRPC](https://grpc.io/) to enable remote application access to the cloud HSM. gRPC is a modern open source high-performance remote procedure call (RPC) framework that can connect services in and across data centers for load balancing, tracing, health checking, and authentication. With gRPC, applications can remotely access the Hyper Protect Crypto Services cloud HSM to call EP11 cryptographic functions. For more information about GREP11 API, see [Introducing EP11 over gRPC](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-grep11-intro).

With the PKCS #11 and GREP11 APIs, you can perform remote cryptographic procedure calls, and, by default, impose message size limits. The maximum receiving message size is 64 MB and the outgoing message size has no limit.





 Comparing the PKCS 11 API with the GREP11 API 

Both the PKCS #11 API and the GREP11 API access the EP11 library that is enabled by the Hyper Protect Crypto Services cloud HSM to execute cryptographic functions. The following diagram illustrates the two options to interact with the cloud HSM.

Zoom

![Performing cryptographic operations with the PKCS #11 API or the GREP11 API](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/hs-crypto//images/pkcs-vs-grep11.svg)

Figure 1. Performing cryptographic operations with PKCS #11 API or GREP11 API
[Obtain your new webhook URL](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-tutorial-expiring-secrets-part-2tutorial-expiring-secrets-part-2-get-webhook).

Now that you've created your action and obtained a new webhook URL, you can add it as an Event Notifications destination. Continue to the next step.







 Step 2: Update your Event Notifications settings 

Next, update your Event Notifications settings so that the service can begin to forward any incoming events from Secrets Manager to your new Cloud Functions action.



1. In the console, click the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/991f60ddbe3ab0a9aa69481a07a0a73b359fa329/icons/icon_hamburger.svg)> Resource list.
2. From the list of resources, select your Event Notifications instance.
3. In the Event Notifications UI, go to Destinations.
4. [Create a destination](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-create-en-destination) so that your alerts can be forwarded to the Cloud Functions webhook that you created the previous step.



1. From the navigation, click Destinations > Add.
2. Provide a name for your destination. For example, Slack.
3. Select Webhook as the destination type.
4. Paste the URL that you copied from the Cloud Functions UI.
5. From the list of HTTP verbs, select POST.
6. Click Add.



After you create your destination, copy your destination ID. You use this value to prepare your Functions code in a later step.





 Create a subscription with webhook signing 

Next, create a new Event Notifications subscription with webhook signing enabled.
--tls-secret, --secret, --tls
: Specify a TLS secret that contains the certificate including all its intermediate certificates and the corresponding private key for the domain mapping. The certificate must be signed by a trusted, public certificate authority (CA). Self-signed certificates are not supported. This value is optional.





 Example 

The following example updates the www.example.com domain mapping to use mytlssecret2 instead of mytlssecret.

ibmcloud ce domainmapping update --domain-name www.example.com --tls-secret mytlssecret2





 Example output 

Updating domainmapping 'www.example.com'...









 Function commands 

A Function is a stateless code snippet that performs tasks in response to an HTTP request. With IBM Code Engine Functions, you can run your business logic in a scalable and serverless way. IBM Code Engine Functions provide an optimized runtime environment to support low latency and rapid scale-out scenarios. Your Function code can be written in in Node.js or Python, which are optimized to run in IBM Code Engine Functions. In addition, your Function code can be written for any OpenWhisk compatible runtime environment or a custom runtime image.

You must be within the context of a [project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-project) before you use function commands.

For more information about working with Functions, see [Working with Functions](https://cloud.ibm.com/docs/codeengine?topic=codeengine-fun-work).



 ibmcloud ce function bind 

Bind an IBM Cloud service instance to a function.

ibmcloud ce function bind --name FUNCTION_NAME (--service-instance SI_NAME | --service-instance-id SI_ID) [--no-wait] [--prefix PREFIX] [--quiet] [--role ROLE] [--service-credential SERVICE_CREDENTIAL] [--wait] [--wait-timeout WAIT_TIMEOUT]



 Command Options
The feed action sets up a ruleT -> pollMyService.



This procedure implements a polling-based trigger entirely by using Cloud Functions actions, without any need for a separate service.





 Implementing feeds by using connections 

The previous two architectural choices are simple and easy to implement. However, if you want a high-performance feed, you can use persistent connections and long-polling or similar techniques.

Since Cloud Functions actions must be short-running, an action cannot maintain a persistent connection to a third party. Instead, you can stand up a separate service, called provider services, outside of Cloud Functions that run all the time. A provider service can maintain connections to third-party event sources that support long polling or other connection-based notifications.

The provider service has a REST API that allows the Cloud Functions feed action to control the feed. The provider service acts as a proxy between the event provider and Cloud Functions. When it receives events from the third party, it sends them on to Cloud Functions by firing a trigger.

The IBM Cloudant changes feed is the canonical example as it stands up a cloudanttrigger service, which mediates between IBM Cloudant notifications over a persistent connection, and Cloud Functions triggers.

The alarm feed is implemented with a similar pattern.

The connection-based architecture is the highest performance option, but operations are more labor-intensive than polling and hook architectures.
This single call is a viable option where a large amount of data needs to be reencrypted with different keys, and bypasses the need to perform a combination of DecryptSingle and EncryptSingle functions for each data item that needs to be reencrypted. For more information, see [GREP11 API reference - ReencryptSingle function](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-grep11-api-refgrep11-ReencryptSingle).

Added: Support for accessing service instances through the Virtual Private Endpoint
: You can now connect your IBM Cloud Virtual Private Cloud (VPC) instance to your Hyper Protect Crypto Services instance through a virtual private endpoint (VPE) gateway, so that you can manage your keys by using Hyper Protect Crypto Services through a private network. For more information, see [Using virtual private endpoints for VPC to privately connect to Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-virtual-private-endpoints-for-vpc).

Added: Support for the SLIP10 mechanism and Edwards-curve algorithm
: Hyper Protect Crypto Services now supports the SLIP10 mechanism for hierarchical deterministic wallets to derive private and public key pairs. It now also supports the Edwards-curve (ED) 25519 algorithm for digital signatures. Before you can use the ED algorithm, make sure to enable this feature by following the instructions in [Enabling Edwards-curve Digital Signature Algorithm](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-enable-mechanismsenable-EdDSA).

Added: Using Terraform to manage Hyper Protect Crypto Services instances and resources
: Terraform is an open source software to configure and automate cloud resource provisioning and management. Now you can provision and initialize Hyper Protect Crypto Services instances, as well as managing root keys and standard keys with the Terraform CLI and the IBM Cloud Provider plug-in.
You can define and set environment variables as key-value pairs that can be used by your application at run time.

You can define environment variables when you create your application, or when you update an existing application from the console or with the CLI.

For more information about defining environment variables, see [Working with environment variables](https://cloud.ibm.com/docs/codeengine?topic=codeengine-envvar).

Code Engine automatically injects certain environment variables into the app. For more information about automatically injected environment variables, see [Automatically injected environment variables](https://cloud.ibm.com/docs/codeengine?topic=codeengine-inside-env-vars).





 Creating and running your app when using secrets and configmaps 

In Code Engine, secrets and configmaps can be consumed by your application by using environment variables.

Both secrets and configmaps are key-value pairs. When mapped to environment variables, the NAME=VALUE relationships are set such that the name of the environment variable corresponds to the "key" of each entry in those maps, and the value of the environment variable is the "value" of that key.

Your application can use environment variables to fully reference a configmap (or secret) or reference individual keys in a configmap (or secret).

For more information, see [referencing secrets by using environment variables](https://cloud.ibm.com/docs/codeengine?topic=codeengine-secretsecret-ref) and [referencing configmaps by using environment variables](https://cloud.ibm.com/docs/codeengine?topic=codeengine-configmapconfigmap-ref).







 Considerations for application quotas 

When you work with applications, functions, and batch jobs, these resources run within the context of a Code Engine project. Resource quotas are defined on a per project basis, and limits apply for applications, functions, and batch jobs.

For more information about Code Engine limits, see [Limits and quotas for Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-limits).
With this option, it makes the IBM public cloud the industry's most secure and open public cloud for business. For a list of services that can be integrated with Hyper Protect Crypto Services, see [Integrating IBM Cloud services with Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-integrate-services).





 Auditing the lifecycle of your keys 

You can use Activity Tracker to monitor the activity of your keys. The Activity Tracker service provides the framework and functions to monitor API calls to services on IBM Cloud and produces the evidence to comply with corporate policies and market industry-specific regulations. Events that are tracked by Activity Tracker are either global or regional, and global events, such as provisioning a service, are available through the global domain instance that is located in Frankfurt. Events that are generated by an instance of Key Protect or Hyper Protect Crypto Services are automatically forwarded to the IBM Cloud instance that is available in the same location.

See [Provisioning an instance](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-provision) to configure your monitoring instance. Whether you're using Key Protect or Hyper Protect Crypto Services, you can track events like creating a key, deleting a key, rotating a key, and more:



* [IBM Cloud Activity Tracker events for Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-at-events)
* [IBM Cloud Activity Tracker events for Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-at-events)
SAP to Cloud Migration Acceleration Program 

SAP Business Applications continue to play a critical role for many Enterprises. IBM Cloud believes “The Best Run SAP”, and we empower those Enterprises; we put smart to work for the Enterprise.

The way that we empower SAP-run businesses, is to merge the functions of SAP business applications with the full capabilities of Cloud for the Enterprise.

We deliver these capabilities, by providing solutions to accelerate SAP implementations and run Enterprises with worldwide, on-demand, SAP-certified Infrastructure and more.

To accelerate our joint customers' success and maximize return on investment as they move SAP workloads to Cloud, IBM Cloud provides the SAP to Cloud Migration Acceleration Program with the following promotional benefits:



*  Price discounts for all SAP-certified Infrastructure within the portfolio (including complementary offerings from IBM Power Systems)
*  Consumption-based credits of your total spend with IBM Cloud (or complementary offerings from IBM Power Systems)



These benefits are available across all IBM Business Partners and channels. Eligibility requirements for this program are amended for each local country and details are available from your local IBM Cloud sales team.

This program is our commitment to helping SAP-run Enterprises, and we work with your chosen services partners to make your journey to Cloud successful.
Creating triggers for events 

In IBM Cloud® Functions, a trigger is a declaration that you want to react to a certain type of event, whether from a user or by an event source.

The following are examples of triggers.



* Location update events
* Document uploads to a website.
* Incoming email





 Creating triggers from the CLI 



1. Create the trigger. Triggers must be created directly within a namespace and can't be created inside packages.

ibmcloud fn trigger create TRIGGER_NAME

The following example shows possible output from the previous command.

ok: created trigger TRIGGER_NAME
2. Verify that the trigger is created.

ibmcloud fn trigger list

The following example shows possible output from the previous command.

triggers
/<namespace_ID>/<TRIGGER_NAME> private



Next, you can [test the trigger](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-testtest_triggers) or [create a rule](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-rules) to associate the trigger with an action.





 Difference between feed and trigger 

Feeds and triggers are closely related, but technically distinct concepts.



* Cloud Functions processes events that flow into the system.
* A trigger is a name for a class of events. Each event belongs to exactly one trigger; by analogy, a trigger resembles a topic in topic-based pub-sub systems. A rule is used to indicate that whenever an event from trigger arrives, invoke action with the trigger payload.
* A feed is a convenient way to configure an external event source to fire trigger events that can be consumed by Cloud Functions. A feed is a stream of events that all belong to some trigger. Pre-installed packages, installable packages, and your own custom packages might contain feeds. A feed is controlled by a feed action, which handles creating, deleting, pausing, and resuming the stream of events that comprise a feed. The feed action typically interacts with external services that produce the events, by using a REST API that manages notifications.
Viewing logs 

Logging can help you troubleshoot issues in IBM Cloud® Code Engine.



 Viewing logs from the console 

When you work with Code Engine apps, jobs, functions, or builds in the console with logging enabled, logs are forwarded to an IBM Log Analysis service where they are indexed, enabling full-text search through all generated messages and convenient querying based on specific fields.

To view logs for your app, job or build in the Code Engine console, you must create an IBM Log Analysis instance in the same region as your Code Engine project. You are not required to create this instance before you work with your Code Engine component. From your Code Engine app, job, function, or build page in the console, you can add logging capabilities.

You need to enable logging for Code Engine only one time per region, per account.



 Considerations for viewing logs from the console 

When you want to use logging from the console, you must first configure IBM Log Analysis platform logs to receive Code Engine logging data. To check for active Log Analysis instances, see the [Observability dashboard](https://cloud.ibm.com/observe/logging).

Review the Log Analysis [service plan](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-service_plans) information as you consider retention, search, and log analysis needs.

When you use the Log Analysis free tier and you want to view log data, configure and launch logging before you start your application, or run your job or build. Also, be sure to keep your platform logs window open to receive your Code Engine logging data. Take these actions because log data is not retained when you use the Lite service plan and is lost when you close the window.

When you use a Log Analysis paid tier, you do not need to leave your logging window open. Log data is preserved for a configurable amount of time, depending on your plan. You can adjust log filters and apply searches for past log entries.

When you view log data for Code Engine applications, runs of your job, or runs of your build, delays can occur before the data is available in Log Analysis.
Function workloads 

A Function is a stateless code snippet that performs tasks in response to an HTTP request. With IBM Code Engine Functions, you can run your business logic in a scalable and serverless way. IBM Code Engine Functions provide an optimized runtime environment to support low latency and rapid scale-out scenarios. Your Function code can be written in in Node.js or Python, which are optimized to run in IBM Code Engine Functions. In addition, your Function code can be written for any OpenWhisk compatible runtime environment or a custom runtime image.



 Lifecycle of a Function instance 

When a Function is invoked, the corresponding Function instance is initialized with the configured Runtime container and Resource parameters. The process of the first initialization is referred to as cold start.

To reduce the cold start latency, Code Engine optimizes the invocation by pre-warming certain runtimes with specific CPU and memory configurations. In addition, the system is designed to improve the reuse of Function instances that are already initialized. Therefore, a Function instance is kept alive after the invocation is finished to allow subsequent invocations by reusing the same instance and reusing the state of the instance when the last invocation completed. How long it is kept alive can be configured by the scale-down-delay option. The reuse of a Function instance is not guaranteed.





 How do Functions compare to apps and jobs? 



Table 1. Comparing Code Engine apps, jobs, and functions

 Characteristic App Job Function 

 Execution time (duration) Long-running 10min per request Long-running up to 24hrs Short-running (<=2mins) 
 Startup latency Medium Scheduled start Low 
 Termination Run-continuously Run-to-completion Run-to-completion 
 Invocation On request or permanently running Scheduled On request, instant 
 Programming Model Container based build and execution Container based build and execution Language specific source code files and dependency meta data 
 Parallelism Parallel execution, flexible Low to medium parallel execution High parallel execution 
 Scale-out Based on number of requests Based on job workload definition Based on events or direct invocations
* If you configured Slack, the toolchain is set up to send notifications about deployment status to the Slack channel that you specified.
* If you configured a source code tool integration such as GitHub, the sample GitHub repo is cloned into your GitHub account.



You can now distribute event notifications by using the [Event Notifications](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-event-notifications-integration) tool integration. IBM Cloud Event Notifications is the preferred method for distributing notifications to PagerDuty and other communication channels such as Slack, email, SMS, push notifications, webhook, Microsoft® Teams, ServiceNow, and IBM Cloud Functions. For more information about using Event Notifications, see [Enabling event notifications for toolchains](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-event-notifications-cd).







 Creating a toolchain from an app by using the console 

You can create a toolchain from your app. The toolchain can support continuous development, deployment, monitoring, and more, and it is associated with your app. Each app can be associated with a toolchain. When you push changes to the toolchain's GitHub repo, the pipeline automatically builds and deploys the app.



1. If you used IBM Cloud Public to create your app, it is configured for continuous delivery from a new GitHub repo that is populated with the app starter code.
2. On the toolchain configuration page, review the diagram of the toolchain that you are about to create. The diagram shows each tool integration in its lifecycle phase in the toolchain.
3. Review the default information for the toolchain settings. The toolchain's name identifies it in IBM Cloud. If you want to use a different name, change the toolchain's name.
4. In the Tool Integrations section, select each tool integration that you want to configure for your toolchain. A few of the tool integrations do not require configuration.
With resource groups, you can organize multiple services in your account and bundle them under one common view and billing process. To allow your team to work with these resources, you can assign IAM access policies to a resource group that allows them to view and manage the resources within a resource group.

For example, you have a team A that is responsible to manage an IBM Cloud Kubernetes Service cluster, and another team B that develops serverless apps with IBM Cloud® Functions. Both teams use IBM Cloud Schematics Workspaces to manage their IBM Cloud resources. To ensure workspace and resource isolation, you create a resource group for each team. Then, you assign the required permissions to each resource group. For example, the Manager service access role to all workspaces in resource group A, but Reader access to the workspaces in resource group B.
* What is the benefit by using IAM access group?

To minimize the number of IAM access policies you need to assign to an individual user, you can create an [IAM access group](https://cloud.ibm.com/docs/account?topic=account-groups) for each team, and assign them all necessary permissions to work with the resources in a resource group.

The following image shows how you can leverage IAM access groups and resource groups to organize permissions in your IBM Cloud account.

![Using resource groups and IAM access groups to organize access to IBM Cloud Schematics](https://cloud.ibm.com/images/schematics-user-flow-rg.png)



1. The account owner or an authorized administrator defines a team and creates an IAM access group for each team.
2. The IAM access group is assigned access to resources within a specific resource group. For example, access group A receives editor permissions for all resources in resource group A, but only viewer permissions for the resources in resource group B.
3. The account owner or an authorized administrator adds users to the IAM access group. All users automatically inherit the permissions of the IAM access group.



* What are the steps to create and restrict the fine-grained and classic personal access tokens (PAT).