vania-janet/multiturn-rag-retrieval-data huggingface dataset:
You cannot use a webhook to call a Cloud Functions action that uses token-based Identity and Access Management (IAM) authentication. However, you can make a call to a Cloud Functions web action or a secured web action.
6. In the Secret field, add a private key to pass with the request that can be used to authenticate with the external service.

The key must be specified as a text string, such as purple unicorn. Maximum length is 1,024 characters. You cannot specify a context variable.

It is the responsibility of the external service to check for and verify the secret. If the external service does not require a token, specify any string you want. You cannot leave this field empty.
7. In the Headers section, add any headers that you want to pass to the service one at a time by clicking Add header.

For example, if the external application that you call returns a response, it might be able to send a response in multiple different formats. The webhook requires that the response is formatted in JSON. The following table illustrates how to add a header that indicates that you want the resulting value to be returned in JSON format.



Header example

 Header name Header value 

 Content-Type application/json 



The service automatically sends an Authorization header with a JWT; you do not need to add one. If you want to handle authorization yourself, add your own authorization header and it will be used instead.



Your webhook details are saved automatically.





 Testing the webhook 

Do extensive testing of your webhook before you enable it for an assistant that is being used in a production environment.

Your assistant must have a skill added to it before your webhook can do anything useful. The webhook is triggered only when a message has been processed by your skill, and a response is ready to be returned.

If you enable the setting that returns an error when the webhook call fails, the processing of the assistant is halted entirely if the webhook encounters any issues. Take steps to test the process that you are calling on a regular basis so you will be alerted if the external service is down, and can take actions to prevent all of the message responses from failing to be returned.
The synchronous HTTP interface of the IBM Watson® Speech to Text service provides a single POST /v1/recognize method for requesting speech recognition with the service. This method is the simplest means of obtaining a transcript. It offers two ways of submitting a speech recognition request:



* The first sends all of the audio in a single stream via the body of the request. You specify the parameters of the operation as request headers and query parameters. For more information, see [Making a basic HTTP request](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-httpHTTP-basic).
* The second sends the audio as a multipart request. You specify the parameters of the request as a combination of request headers, query parameters, and JSON metadata. For more information, see [Making a multipart HTTP request](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-httpHTTP-multi).



Submit a maximum of 100 MB and a minimum of 100 bytes of audio data with a single request. For information about audio formats and about using compression to maximize the amount of audio that you can send with a request, see [Supported audio formats](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-audio-formats). For information about all methods of the HTTP interface, see the [API & SDK reference](https://cloud.ibm.com/apidocs/speech-to-text).



 Making a basic HTTP speech recognition request 

The HTTP POST /v1/recognize method provides a simple means of transcribing audio. You pass all audio via the body of the request and specify the parameters as request headers and query parameters.

The method returns results only after it processes all of the audio for a request. The method is appropriate for batch processing but not for live speech recognition. Use the WebSocket interface to transcribe live audio.

If your data consists of multiple audio files, the recommended means of submitting the audio is by sending multiple requests, one for each audio file.
* --vnc: Get the WebSocket URI for the VNC console and open the IBM Cloud web VNC console in the browser for the instance.
* -q, --quiet: Suppress verbose output.



--------------------







 ibmcloud is instance-create 

Create a virtual server instance.

ibmcloud is instance-create INSTANCE_NAME VPC ZONE_NAME PROFILE_NAME SUBNET [--image IMAGE | --catalog-offering CATALOG_OFFERING | --catalog-offering-version CATALOG_OFFERING_VERSION] [--total-volume-bandwidth TOTAL_VOLUME_BANDWIDTH] [--boot-volume BOOT_VOLUME_JSON | @BOOT_VOLUME_JSON_FILE] [--volume-attach VOLUME_ATTACH_JSON | @VOLUME_ATTACH_JSON_FILE] [--keys KEYS] [--dedicated-host DEDICATED_HOST | --dedicated-host-group DEDICATED_HOST_GROUP | --placement-group PLACEMENT_GROUP] [--user-data DATA] [(--sgs SGS] --rip RIP | (--address ADDRESS --auto-delete true | false --ip-name IP_NAME)] --allow-ip-spoofing false | true]) | --primary-network-interface PRIMARY_NETWORK_INTERFACE_JSON | @PRIMARY_NETWORK_INTERFACE_JSON_FILE] [--network-interface NETWORK_INTERFACE_JSON | @NETWORK_INTERFACE_JSON_FILE] [--default-trusted-profile DEFAULT_TRUSTED_PROFILE --default-trusted-profile-auto-link true,false]] [--metadata-service, --ms true | false --metadata-service-protocol, --msp http | https | --metadata-service-response-hop-limit, --msrhl METADATA_SERVICE_RESPONSE_HOP_LIMIT,MSRHL]] [--host-failure-policy restart | stop] [--resource-group-id RESOURCE_GROUP_ID | --resource-group-name RESOURCE_GROUP_NAME] [--output JSON] [-i, --interactive] [-q, --quiet]



 Command examples
Extracting notifications from Monitoring to IBM Cloud Event Streams 

You can extract notifications from Monitoring to IBM Cloud Event Streams by using the Event Streams REST API.

Complete the following steps:



 Step 1. Provision an Event Streams instance and provision a topic 

Complete the following steps:



1. Provision an Event Streams instance with an Enterprise Plan. Ensure that the Event Streams instance uses private endpoints.
2. Create a topic in the Event Streams instance, for example, my-sample-topic.







 Step 2. Obtain the Event Streams API connection details 

Obtain the following Event Streams API connection details that you must use when you configure the notification channel:



* api_key
* kafka_http_url



Choose 1 of the following methods:



 Get credentials using the IBM Cloud console 



1. Locate your Event Streams service on the dashboard.
2. Click your service tile.
3. Click Service Credentials.
4. Click New Credential.
5. Complete the details for your new credential like a name and role and click Add. A new credential appears in the credentials list.
6. Click this credential by using View Credentials to reveal the details in JSON format.







 Get credentials using the IBM Cloud CLI 

Complete the following steps:



1. Locate your service instance.

ibmcloud resource service-instances
2. Create a service key via the command line.

ibmcloud resource service-key-create KEY_NAME Writer --instance-name INSTANCE_NAME --service-endpoint private

Where KEY_NAME is the name of the key, and INSTANCE_NAME is the name of the Event Streams instance.

The output of this command includes the details that are needed to make a REST call to send notifications to the Event Streams instance.









 Step 3. Create a notification channel 

From the Monitoring UI, setup a Webhook notification channel.

Complete the following steps to add a notification channel:



1. Launch the web UI.
Overview 

IBM® Event Streams for IBM Cloud® is a high-throughput message bus that is built with Apache Kafka. It is optimized for event ingestion into IBM Cloud® and event stream distribution between your services and applications. Event Streams was previously known as Message Hub.

You can use Event Streams to complete the following tasks:



*  Offload work to back-end worker applications.
*  Connect Event Streams to streaming analytics to realize powerful insights.
*  Publish event data to multiple applications to react in real time.



Event Streams offers a fully managed Apache Kafka service, ensuring durability and high availability for our clients. By using Event Streams, you have support around the clock from our team of Kafka experts.

By being built with Apache Kafka, our offering directly benefits from all the innovation that occurs in the community and supports Kafka client APIs, Kafka Streams, and Kafka Connect. Kafka is highly reliable and lets you build scalable data pipelines for many use cases, including connecting microservices, doing log aggregation, event sourcing, and stream processing.

Apache Kafka tools usually work directly with Event Streams, although you do need to provide more configuration because connections to Event Streams always authenticate by using credentials.

In Event Streams, applications send data by creating a message and sending it to a topic. To receive messages, applications subscribe to a topic and choose to either receive all the topic's messages, or to share the messages between them. Event Streams hosts and maintains the messages in an ordered sequence.
See [Do Code Engine apps support WebSockets](https://cloud.ibm.com/docs/codeengine?topic=codeengine-faqsapp-websockets)?

Updated versions for buildpacks.
: See [Choosing a build strategy](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-buildbuild-strategy).





 7 July 2021 

Review the release notes for 7 July 2021.

Environment variables
: Updated information about automatically injected environment variables for Code Engine apps and jobs. See [Automatically injected environment variables](https://cloud.ibm.com/docs/codeengine?topic=codeengine-inside-env-vars).

Troubleshooting overview topics
: Added troubleshooting overview topics for apps, builds, jobs, projects, and subscriptions. See [Debugging apps](https://cloud.ibm.com/docs/codeengine?topic=codeengine-troubleshoot-apps), [Debugging builds](https://cloud.ibm.com/docs/codeengine?topic=codeengine-troubleshoot-build), [Debugging jobs](https://cloud.ibm.com/docs/codeengine?topic=codeengine-troubleshoot-job), [Debugging projects](https://cloud.ibm.com/docs/codeengine?topic=codeengine-troubleshoot-project), [Debugging subscriptions](https://cloud.ibm.com/docs/codeengine?topic=codeengine-troubleshoot-subscriptions).

Object Storage buckets
: Code Engine supports Object Storage buckets that are located in the jp-osa region. See [Set up the IBM Cloud Object Storage event producer](https://cloud.ibm.com/docs/codeengine?topic=codeengine-eventing-cosevent-producersetup-cosevent-producer).







 June 2021 

Review the release notes for June 2021.



 30 June 2021 

Review the release notes for 30 June 2021.
A similar feed action protocol occurs for ibmcloud fn trigger delete, ibmcloud fn trigger update, and ibmcloud fn trigger get.





 Implementing feeds with hooks 

Set up a feed by using a hook when an event producer supports a webhook-callback facility.

With this method, you are not required to stand up any persistent service outside of Cloud Functions. All feed management happens naturally though stateless Cloud Functions feed actions, which negotiate directly with a third-party webhook API.

When invoked with CREATE, the feed action simply installs a webhook for some other service, asking the remote service to POST notifications to the appropriate fireTrigger URL in Cloud Functions.

The webhook is directed to send notifications to a URL such as, POST /namespaces/{namespace_ID}/triggers/{triggerName}

The form with the POST request is interpreted as a JSON document that defines parameters on the trigger event. Cloud Functions rules pass these trigger parameters to any actions to fire because of the event.





 Implementing feeds with polling 

You can set up an action to poll a feed source entirely within Cloud Functions, without the need to stand up any persistent connections or external service.

For feeds where a webhook is not available, but do not need high-volume or low latency response times, you can use polling.

To set up a polling-based feed, the feed action takes the following steps when called for CREATE:



1. The feed action sets up a periodic trigger with a specific frequency, by using the whisk.system/alarms feed.
2. The feed developer creates a pollMyService action that polls the remote service and returns any new events.
3. 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.
}
const token = jwt.sign(payload, process.env.YOUR_PRIVATE_RSA_KEY, { algorithm: 'RS256', expiresIn: '10000ms' });
return token;
}
Show more
3. The encrypted user payload is decrypted and then saved to the context.integrations.chat.private.user_payload object.

For information about how to access the payload data from the dialog, see [Web chat: Accessing sensitive data](https://cloud.ibm.com/docs/assistant?topic=assistant-dialog-integrationsdialog-integrations-chat-private). You might want to access the payload, for example, to get the customer importance information or single sign-on credentials that you can subsequently use to authenticate a webhook.







 Authenticating users 

To authenticate and specify a unique ID for each customer, add the user ID information to the token.



1. From the web chat configuration page, copy the public key from the IBM provided public key field. You will specify this value as the PUBLIC_IBM_RSA_KEY later.
2. From your website, write a function that signs a JSON Web Token.

The function must accept a UserID parameter and set the userID as the sub claim value.

For example, the following NodeJS code snippet set the user's ID to L12345.

// Sample NodeJS code on your server.
const jwt = require('jsonwebtoken');
const RSA = require('node-rsa');

const rsaKey = new RSA(process.env.PUBLIC_IBM_RSA_KEY);

/
* Returns a signed JWT. Optionally, adds an encrypted user payload in stringified JSON.
/
function mockLogin() {
const payload = {
sub: 'L12345', // Required
iss: 'www.example.com' // Required
};
Building a network with APIs 

The IBM® Blockchain Platform exposes RESTful APIs for you to create, import, edit, and delete your blockchain components, as well as to manage logging, notifications, and console settings. You can use the APIs, and the corresponding SDKs, to develop applications that interact with your blockchain network.

This tutorial introduces the generic flow to build a blockchain network with IBM Blockchain Platform APIs. For more information about each API, see [IBM Blockchain Platform API reference doc](https://cloud.ibm.com/apidocs/blockchain).



 Swagger 

After you review the instructions in this topic on how to use the APIs, you can alternatively access a Swagger version of the APIs instead of the [APIs in IBM Cloud](https://cloud.ibm.com/apidocs/blockchain) where the current version is v2. If you need to access the v1 version of the APIs, you can import the v1 version into the [Swagger editor](http://editor.swagger.io).



* [v1](https://github.com/ibm-cloud-docs/blockchain/blob/master/reference/ibp-v1.yaml)
* [v2](https://github.com/ibm-cloud-docs/blockchain/blob/master/reference/ibp-v2.yaml)







 Before you begin 

You must have an IBM Blockchain Platform service instance in IBM Cloud so that you can issue API calls to interact with the network. If you do not have a service instance yet, follow the [Getting started instructions](https://cloud.ibm.com/docs/blockchain/reference?topic=blockchain-ibp-v2-deploy-iksibp-v2-deploy-iks) to create one.





 Authentication 

In order to use the APIs to access your blockchain network that you create with IBM Blockchain Platform, your application needs to be able to authenticate with IBM Cloud and connect to your service instance.



 Retrieving service credentials
async function verifySignature(keysArray, kid, jws) {
const keyJson = keysArray.find(key => key.kid === kid);
if (keyJson) {
const pem = jwkToPem(keyJson);
await jwtVerify(jws, pem);
return;
}
throw new Error ("Unable to verify signature");
}

async function verifyAndSendMail(jws) {
// The API key for Sendgrid
const sgApiKey = '<SengridApiKey>';

// Init Sendgrind
sgMail.setApiKey(sgApiKey);

// Decode message to get information
const data = jwtDecode(jws, {complete: true});

// Extract kid from header
const kid = data.header.kid;

const keysArray = await obtainPublicKeys();

// Verify the signature of the payload with the public keys
await verifySignature(keysArray, kid ,jws);

// Send the email with Your Sendgrid account
const message = data.payload.message;
const msg = {
to: message.to,
from: message.from.address,
subject: message.subject,
html: message.body,
};
console.log(Sending email to ${message.to});
let sendgridResponse = await sgMail.send(msg);

return {result : 'email_sent',sendgridResponse};
}
2. Make a PUT request to the /management/v4/<tenantID>/config/cloud_directory/email_dispatcher to provide your webhook URL. Optionally, you can provide authorization information. Supported authorization types include: Basic authorization and constant authorization header value.
Fabric supports three SDKs: [Go](https://github.com/hyperledger/fabric-sdk-go), [Node](https://github.com/hyperledger/fabric-sdk-node), and [Java](https://github.com/hyperledger/fabric-sdk-java)) that include documentation for the available APIs.





 Service credentials 

Service credentials are in JSON format and contain the API endpoint information and enrollIDs/secrets for your network resources, that is, CAs, ordering nodes, and peers. Your application interacts with network resources through these API endpoints.





 Service discovery 

Fabric [service discovery](https://hyperledger-fabric.readthedocs.io/en/release-2.2/discovery-overview.html) allows your client applications to dynamically find the peer and ordering endpoints of your network. If you do not configure service discovery in your application, the endpoint information of peer and ordering nodes on your channel needs to be added manually to your connection profile or your application.





 Shim 

When referring to smart contracts or chaincode, the shim represents a set of Hyperledger Fabric chaincode APIs that a smart contract can use to access state variables, transaction context, and call other smart contracts.





 SignCert 

The certificate that any entities, whether organizations or admins, attach to their proposals or proposal responses. These signCerts are unique to an entity and are checked by the ordering service to make sure they match the signCert on file for that entity.





 Smart contracts 

See [Chaincode](https://cloud.ibm.com/docs/blockchain?topic=blockchain-glossaryglossary-chaincode).





 Smart contract definition 

Used by the Hyperledger Fabric v2.x smart contract lifecycle, the smart contract definition contains the elements that members of an organization agree to before a smart contract can be committed to a channel. The definition is composed of a smart contract definition name, version, endorsement policy, and private data collection.
For a Java client, the following example shows the minimum set of properties, where ${USERNAME}, ${PASSWORD}, and ${BOOTSTRAP_ENDPOINTS} are to be replaced by the values that you retrieved previously.

bootstrap.servers=${BOOTSTRAP_ENDPOINTS}
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="${USERNAME}" password="${PASSWORD}";
security.protocol=SASL_SSL
ssl.protocol=TLSv1.2
ssl.enabled.protocols=TLSv1.2
ssl.endpoint.identification.algorithm=HTTPS

If you use a Kafka client earlier than version 0.10.2.1, the sasl.jaas.config property isn't supported, and you must instead provide the client configuration in a JAAS configuration file.





 Using SASL OAUTHBEARER 

Before configuring the SASL mechanism for Java client, there are two prerequisites.



* The minimum supported Kafka Java client version is 3.1.0.
* Additional jar package needs to be downloaded from Maven Central and made available in the classpath.



If Maven is used in build system, add the following information to the file pom.xml in the dependencies section.

<dependency>
<groupId>com.ibm.eventstreams</groupId>
<artifactId>oauth-client</artifactId>
<version>0.1.2</version>
</dependency>

If Gradle is used in build system, add the following information to the file build.gradle in the dependencies section.

implementation com.ibm.eventstreams:oauth-client:0.1.2

Use the following strings and properties.



* Use the bootstrap_endpoints string as the list of bootstrap servers and pass this string of host and port pairs to your Kafka client.
* Use the api_key string as the API key.
* URL: https://us-south.functions.appdomain.cloud/api/v1/web/e97d2516-5ce4-4fd9-9d05-acc3dd8ennn/southernize/add_southern_charm
* Secret: none
* Header name: Content-Type
* Header value: application/json



The postmessage webhook calls an IBM Cloud Functions web action name add_southern_charm.

The node.js code in the add_southern_charm web action looks as follows:

function main(params) {
console.log(JSON.stringify(params))
if (params.payload.output.generic[0].text !== '') {
//Get the length of the input text
var length = params.payload.output.generic[0].text.length;
//create a substring that removes the last character from the input string, which is typically punctuation.
var revision = params.payload.output.generic[0].text.substring(0,length-1);
const response = {
body : {
payload : {
output : {
generic : [
{
//Replace the input text with your shortened revision and append y'all to it.
"response_type": "text",
"text": revision + ', ' + 'y'all.'
}
],
},
},
},
};
return response;
}
else {
return {
body : params
}
}
}
Show more





 Example 2 

This example shows you how to translate a message response back to the customer's native language. It only works if you perform the steps in [Example 2](https://cloud.ibm.com/docs/assistant-data?topic=assistant-webhook-prewebhook-pre-example-translate) to define a premessage webhook that translates the original message into English.