vania-janet/multiturn-rag-retrieval-data huggingface dataset:
When you are done, click the X to close the node. Your changes are automatically saved.







 Testing webhooks 

When you first add a webhook callout, it can be useful to see exactly what is returned in the response from the external application, the data and its format. To do this, add this expression as the text response for the successful callout conditional response: $webhook_result_n where n is the appropriate number for the webhook you are testing.

This response returns the full body of the return variable, so you can see what the callout is sending back and decide what to share with the user. You can then use the methods documented in [Expression language methods](https://cloud.ibm.com/docs/assistant?topic=assistant-dialog-methods) to extract only the information you care about from the response.

Test whether certain user inputs can generate errors in the callout, and build in ways to handle those situations. Errors generated by the external application are stored in output.webhook_error.<result_variable>. You can use a conditional response like this while you are testing to capture such errors:



 Condition Response 

 output.webhook_error The callout generated this error: . 



For example, you might not be authenticating the request properly (401), or you might be trying to pass a parameter with a name that is already in use by the external application. Test the webhook to discover and fix these types of errors before you deploy the webhook.





 Removing a webhook 

If you decide you do not want to make a webhook call from a dialog node, open the node's Customize page, and then switch Webhooks Off.

The Parameters section and the Return variable field are removed from the dialog node editor. However, any conditional responses that were added for you or that you added yourself remain.

The Multiple conditioned responses section is editable again. You can choose to switch the feature off. If you do so, then only the first conditional response is saved as the node's only text response.
ddoc: 'allusers',
view: 'getVerifiedEmails',
limit: 10
}).then(response => {
console.log(response.result);
});

from ibmcloudant.cloudant_v1 import CloudantV1

service = CloudantV1.new_instance()

response = service.post_view(
db='users',
ddoc='allusers',
view='getVerifiedEmails',
limit=10
).get_result()

print(response)

postViewOptions := service.NewPostViewOptions(
"users",
"allusers",
"getVerifiedEmails",
)

postViewOptions.SetLimit(10)

viewResult, response, err := service.PostView(postViewOptions)
if err != nil {
panic(err)
}

b, _ := json.MarshalIndent(viewResult, "", " ")
fmt.Println(string(b))

The previous Go example requires the following import block:

import (
"encoding/json"
"fmt"
"github.com/IBM/cloudant-go-sdk/cloudantv1"
)

All Go examples require the service object to be initialized. For more information, see the API documentation's [Authentication section](https://cloud.ibm.com/apidocs/cloudant?code=goauthentication-with-external-configuration) for examples.

See the following example response to the request:

{
"offset": 0,
"rows": [
{
"id": "abc125",
"key": "amelie.smith@aol.com",
"value":
"Amelie Smith",
true,
"2020-04-24T10:42:59.000Z"
]
},
{
measure: 'QUERY',
quantity: 0,
},
{
measure: 'GIGABYTE',
quantity: 0,
}];

const resourceInstanceUsageModel = {
resource_instance_id: resourceInstanceId,
plan_id: planId,
region: region,
start: startTime,
end: endTime,
measured_usage: measures,
};

const params = {
resourceId: resourceId,
resourceUsage: [resourceInstanceUsageModel],
};

usageMeteringService.reportResourceUsage(params)
.then(res => {
console.log(JSON.stringify(res.result, null, 2));
})
.catch(err => {
console.warn(err)
});





 Response 

The response body includes the acceptance status of every usage record. A successful submission returns a response code of 201. If any other response code is returned, update and resend the data until you receive the 201 code. See the following example of a successful response:

{
"resources": [
{
"code": "successful_submission",
"status": 201,
"message": "Payload was successfully submitted",
"details":
{
"field": "data.resource_instance_id",
"message": "is required",
"value": {
"start": 1501282845663,
"end": 1501282845664,
"region": "us-south",
"plan_id": "04082014.ibm.node.default",
"measured_usage":
{
"measure": "current_running_instances",
"quantity": 1
},
{
"measure": "current_instance_memory",
"quantity": 1
}
]
},
Web actions can be invoked without authentication and can be used to implement HTTP handlers that respond with headers, statusCode, and body content of different types.

Web actions must return a JSON object. However, the controller treats a web action differently if its result includes one or more of the properties as top-level [JSON properties](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-actions_webweb_action_properties).





 Packaging code for web actions 

Cloud Functions actions can be web-enabled by including the --web true flag in the [action create command](https://cloud.ibm.com/docs/openwhisk?topic=cloud-functions-cli-plugin-functions-clicli_action_create).

You can create a web action from multiple app files by packaging them as a .zip archive. You can also create a web action by using Docker images.



* To learn how to package your code for actions, see [Preparing apps for actions](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-prep).
* To see more examples of how you can create actions, see [Creating actions](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-actions).







 Available features of web actions 

Web actions support the following features:



 Content extensions 

You can specify a content type for your web action response by adding an extension to the action name in the URI. The following content types are supported: .json, .http, .html, .svg, or .text. For example, an action <namespace_ID>/demo/hello is referenced as <namespace_ID>/demo/hello.json to receive a .json response. \n For content type .json, the full return object is returned, similar to {resOne: "some text", resTwo: 42}. \n For .html, .svg, or .text, the content of the property that is called body is returned, similar to .http.
Handle errors programmatically by including the Composer library within the action implementation. By using the library, you can chain together a sequence of actions or define other types of control-flow logic. When you use this library, all execution of the [error-handling code occurs service-side](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-pkg_composererror-handling) and there are no additional components that you must manage. To articulate the error-handling logic programmatically, import the Composer library, a common practice in the programming language communities. For more information about installing and using the Composer library with Cloud Functions, see [Composer](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-pkg_composer).
db: 'users',
ddoc: 'allusers',
view: 'getVerifiedEmails',
startKey: 'alpha',
endKey: 'beta'
}).then(response => {
console.log(response.result);
});

from ibmcloudant.cloudant_v1 import CloudantV1

service = CloudantV1.new_instance()

response = service.post_view(
db='users',
ddoc='allusers',
view='getVerifiedEmails',
start_key='alpha',
end_key='beta'
).get_result()

print(response)

postViewOptions := service.NewPostViewOptions(
"users",
"allusers",
"getVerifiedEmails",
)

postViewOptions.StartKey = "alpha"
postViewOptions.EndKey = "beta"

viewResult, response, err := service.PostView(postViewOptions)
if err != nil {
panic(err)
}

b, _ := json.MarshalIndent(viewResult, "", " ")
fmt.Println(string(b))

The previous Go example requires the following import block:

import (
"encoding/json"
"fmt"
"github.com/IBM/cloudant-go-sdk/cloudantv1"
)

All Go examples require the service object to be initialized. For more information, see the API documentation's [Authentication section](https://cloud.ibm.com/apidocs/cloudant?code=goauthentication-with-external-configuration) for examples.

For example, if you have a database that returns one result when you use a start_key of alpha and an end_key of beta, you would get a 400 (Bad request) error with a reversed order.
The String data type can be of the format of a text string, JSON or YAML. Accordingly, the SDK processes each format as shown in Table 1.



Table 1. Example outputs

 Feature or Property value Data type Data format Type of data returned by getCurrentValue() Example output 

 true BOOLEAN not applicable java.lang.Boolean true 
 25 NUMERIC not applicable java.lang.Integer 25 
 a string text STRING TEXT java.lang.String a string text 
 {"firefox": { <br>"name": "Firefox", <br>"pref_url": "about:config" <br>}} STRING JSON org.json.JSONObject {"firefox":{"name":"Firefox","pref_url":"about:config"}} 
 men: <br>- John Smith <br>- Bill Jones <br>women: <br>- Mary Smith <br>- Susan Williams STRING YAML java.lang.String `"men:<br><br><br><br> * John Smith<br> * Bill Jones\women:<br> * Mary Smith<br> * Susan Williams"`<br><br><br> 





 Feature flag 

val feature: Feature? = appConfiguration.getFeature("json-feature")
feature.getFeatureDataType(); // STRING
feature.getFeatureDataFormat(); // JSON

// Example below (traversing the returned JSONObject)
if (feature != null) {
val result = feature.getCurrentValue(entityId, entityAttributes) as JSONObject
result.get("key") // returns the value of the key
}

val feature: Feature? = appConfiguration.getFeature("yaml-feature")
feature.getFeatureDataType(); // STRING
feature.getFeatureDataFormat(); // YAML
Calling a client application ![BETA](https://cloud.ibm.com/docs-content/v1/content/a2b18c153837bce00a5b4de496e4b4ca64bbf56e/assistant-data/images/beta.png) 

Add a client action to your dialog node that pauses the dialog so a client-side process can run and return a result as part of the processing that occurs within a dialog turn.

Support for this feature was introduced with version 1.4.

A client action defines a programmatic call in a standardized format that your external client application can understand. Your external client application must use the provided information to run the programmatic call or function, and then return the result to the dialog.

This action does not make a direct call itself. It basically tells the dialog to pause here and wait for an external client application to go do something. The program that the client application runs can be anything that you choose. Be sure to specify the call name and parameter details, and the error message variable name according to the JSON formatting rules that are outlined later in this topic.

You can call a client application to do the following types of things:



* Validate information that you collected from the user.
* Do calculations or string manipulations on user input that are too complex for supported SpEL expression methods to handle.
* Get data from another application or service.



For information about how to call an external service, such as a Cloud Functions web action, see [Making a programmatic call from a dialog node](https://cloud.ibm.com/docs/assistant-data?topic=assistant-data-dialog-webhooks).

The following diagram illustrates how you can use a client call to get weather forecast information, and return it to the user.

!
A 307 in response to a POST, PUT, or DELETE indicates that the server has not even tried to perform the operation and the client needs to resubmit the entire request, with the original method, to the URI in the Location header.







 Client errors: 4xx 



Client error status codes

 Code Meaning Description 

 400 [Bad Request](https://datatracker.ietf.org/doc/html/rfc7231section-6.5.1) This code MUST be returned when a request cannot be processed due to client error (e.g., the request is malformed or too large) when a more specific code is not applicable. 
 401 [Unauthorized](https://datatracker.ietf.org/doc/html/rfc7235section-3.1) This code MUST be returned when a request needs to be authenticated to succeed or the credentials provided are invalid. Responses with a 401 status code MUST also provide a valid WWW-Authenticate header.<br><br>[6] 
 403 [Forbidden](https://datatracker.ietf.org/doc/html/rfc7231section-6.5.3) This code SHOULD be returned when the client is not allowed to make the desired request. This status SHOULD be returned if the client is properly authenticated but does not possess permission to perform the request, or if the client is not authenticated, but authentication would not affect the outcome. 
 404 [Not Found](https://datatracker.ietf.org/doc/html/rfc7231section-6.5.4) This code SHOULD be returned when the requested resource could not be found but may be available in the future. This status code MAY also be used for security reasons in the scenario [described below](https://cloud.ibm.com/docs/api-handbook?topic=api-handbook-status-codessecurity-implications-of-401-and-403). 
 405 [Method Not Allowed](https://datatracker.ietf.org/doc/html/rfc7231section-6.5.5) This code SHOULD be returned when the requested resource doesn't support the request method.
6. You get an activity ID in response if the parameters passed as part of the request are valid. You should see the plan being applied in the Schematics workspace that you created in the IBM Cloud console. If you don’t get a successful response, the error response contains the errors that you need to resolve. Resolve those errors and run the script until you are able to get a valid response and apply a plan.
7. If you want to check the logs of the action, see [Retrieving action logs with Schematics API](https://cloud.ibm.com/docs/ibm-spectrum-lsf?topic=ibm-spectrum-lsf-retrieve-action-logs) to retrieve the logs. The response contains the status of the action, and it appears in either a COMPLETED or FAILED state.





 Example Python request 

 Apply a plan using Schematics Python API

import json, logging

from ibm_cloud_sdk_core.authenticators import IAMAuthenticator
from ibm_schematics.schematics_v1 import SchematicsV1

logging.basicConfig()
logging.root.setLevel(logging.NOTSET)
logging.basicConfig(level=logging.NOTSET)

authenticator = IAMAuthenticator('<ibmcloud-api-key>')

schematics_service = SchematicsV1(authenticator = authenticator)

schematics_service.set_service_url('https://us.schematics.cloud.ibm.com')

logging.info("Started Applying Schematic Plan")

workspace_activity_apply_result = schematics_service.apply_workspace_command(
    w_id='<workspace id>',
    refresh_token='<refresh-token>'
).get_result()

print(json.dumps(workspace_activity_apply_result, indent=2))

logging.info("Completed Applying Schematic Plan")





 Example Python response 

INFO:root:Started Applying Schematic Plan
if (data != null && data.Contents != null) {
for (var i = 0; i < data.Contents.length; i++) {
var itemKey = data.Contents[i].Key;
var itemSize = data.Contents[i].Size;
console.log(Item: ${itemKey} (${itemSize} bytes).)
}
}
})
.catch((e) => {
console.error(ERROR: ${e.code} - ${e.message}n);
});
}
Show more

SDK References



* [listObjects](https://ibm.github.io/ibm-cos-sdk-js/AWS/S3.htmllistObjects-property)







 Get file contents of particular item 

function getItem(bucketName, itemName) {
console.log(Retrieving item from bucket: ${bucketName}, key: ${itemName});
return cos.getObject({
Bucket: bucketName,
Key: itemName
}).promise()
.then((data) => {
if (data != null) {
console.log('File Contents: ' + Buffer.from(data.Body).toString());
}
})
.catch((e) => {
console.error(ERROR: ${e.code} - ${e.message}n);
});
}

SDK References



* [getObject](https://ibm.github.io/ibm-cos-sdk-js/AWS/S3.htmlgetObject-property)







 Delete an item from a bucket 

function deleteItem(bucketName, itemName) {
console.log(Deleting item: ${itemName});
return cos.deleteObject({
Bucket: bucketName,
Key: itemName
}).promise()
workspace_activity_apply_result = schematics_service.apply_workspace_command(
    w_id='<workspace id>',
    refresh_token='<refresh-token>'
).get_result()

print(json.dumps(workspace_activity_apply_result, indent=2))

logging.info("Completed Applying Schematic Plan")





 Example Python response 

INFO:root:Started Applying Schematic Plan
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): iam.cloud.ibm.com:443
DEBUG:urllib3.connectionpool:https://iam.cloud.ibm.com:443 "POST /identity/token HTTP/1.1" 200 985
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): us.schematics.cloud.ibm.com:443
DEBUG:urllib3.connectionpool:https://us.schematics.cloud.ibm.com:443 "PUT /v1/workspaces/us-south.workspace.Schematic-Sunil-Test-Workspace.5a4cbf11/apply HTTP/1.1" 202 49
{
  "activityid": "33bade478b4e93f5c613e4f62943ad9a"
}
INFO:root:Completed Applying Schematic Plan
mymicroservicerepo: <PR > - (Merge pull request 15 implemented myfunction)



* TEST AND SCANS RESULTS No issues are found if no failures are reported in the evidence summary or the list of failed IDs. For example, com.ibm.cloud.image_vulnerability_scan: failed; com.ibm.unit_tests: failed), with the abstract of the issues opened so that the approver can view details about what is failing.







 Additional attachments 

The change requests include attachments for the evidence summary, the deployment BOM, and the closing summary.



* Evidence summary Contains the key information about test and scan results, and the issues that were created while you were running them. The entries in the evidence summary are a reformatted version of the summary.json file.
* Deployment BOM A list of all of the artifacts, together with their digital signature or checksum that is transferred into the target environment to successfully run the deployment.
* Closing summary The summary of all of the evidence that relates to the current deployment when the change request is closed.







 Rollback 

The rollback section provides the following information:



* The version to roll back to.
* The steps to follow if the rollback includes more than just the deployment of the previous version.
// input json :- {"role": "tester", "description": "do testing"}
// expected output :- "tester"

tar_val = property.get_current_value(entityId, entityAttributes)
expected_output = tar_val['role']

property = appconfig_client.get_property('yaml-property')
property.get_property_data_type() // STRING
property.get_property_data_format() // YAML
property.get_current_value(entityId, entityAttributes) // returns dictionary object

// Example Below
// input yaml string :- "---nrole: testerndescription: do_testing"
// expected output :- "do_testing"

tar_val = property.get_current_value(entityId, entityAttributes)
expected_output = tar_val['description']
Show more





 Set listener for the feature and property data changes 

The SDK provides mechanism to notify you in real time when feature flags' or properties' configuration changes. You can subscribe to configuration changes by using the same appconfig_client.

def configuration_update(self):
print('Received updates on configurations')
 add your code
 To find the effect of any configuration changes, you can call the feature or property related methods

 feature = appconfig_client.getFeature('online-check-in')
 new_value = feature.get_current_value(entity_id, entity_attributes)

appconfig_client.register_configuration_update_listener(configuration_update)





 Fetch latest data 

appconfig_client.fetch_configurations()
console.log("ReferTransferTarget: " + event.ReferTransferTarget);

const referToSipUriHeaders = event.ReferTransferTarget.split("?")[1];
console.log(referToSipUriHeaders);
if (referToSipUriHeaders) {
const sanitizedReferToSipUriHeaders = referToSipUriHeaders.replace(">", "");
console.log("Custom Headers: " + sanitizedReferToSipUriHeaders);

const sipHeadersList = sanitizedReferToSipUriHeaders.split("&");

const sipHeaders = {};
for (const sipHeaderSet of sipHeadersList) {
const [name, value] = sipHeaderSet.split('=');
sipHeaders[name] = value;
}

const USER_TO_USER_HEADER = 'User-to-User';

// Extracts the User-to-User header value
const uuiData = sipHeaders[USER_TO_USER_HEADER];

if (uuiData) {
const decodedUUIData = decodeURIComponent(uuiData);
const sessionHistoryKey = decodedUUIData.split(';')[0];
// Passes the session history key back to Twilio Studio through a query parameter.
studioWebhookReturnUrl = ${studioWebhookReturnUrl}&SessionHistoryKey=${sessionHistoryKey};
}
}

response.redirect(
{ method: 'POST' },
studioWebhookReturnUrl
);

// This callback is what is returned in response to this function being invoked.
// It's really important! E.g. you might respond with TWiML here for a voice or SMS response.
// Or you might return JSON data to a studio flow. Don't forget it!
* Having proper agreements in place, and obtaining all required permissions, with Client’s user for any user data Client transfers to the hardware.



Include a pre-paid return-shipping label and all appropriate export documents with your shipment. IBM Cloud® packages the device for return by using the label and documents that you provided. If return isn't requested, the device is destroyed.





 What types of devices can be sent with a data transfer request? 

Use the following Hardware Requirements guidelines when you select a device to submit for data transfer.



* Power supply must be 208v/220v compatible.
* Power plug must fit a standard 120v socket (NEMA 5-15P).
* Device must be USB 2.0 or USB 3.0 compatible.
* Provide a USB A male connector (standard USB plug that fits most computers).

Encrypted USB devices that require support for proprietary encryption software are not supported for data transfer.







 Can the device be sent back sooner or can it stay longer than two weeks? 

Yes, your hardware can be returned at any time or can stay connected longer, if necessary. To request a return on an extension, add a comment to the original data transfer request case with the appropriate request. If you request a return, IBM Cloud® disconnects and returns the hardware to the return address provided in the original request by using the pre-paid shipping labels and packaging that you provided.

If you request an extension, the extension request is processed as quickly as possible. It's important to note that each extension request extends the time that the device is connected for one week and can be subject to an extension fee. More details are added when a member of the IBM Cloud® team responds to the request in the original ticket.

Each status on the data transfer case indicates the phase of the transfer process for the hardware that was submitted to the data center. Refer to the table for specific details on each status:



Table 1. Status definitions.

 Status Definition 

 Sent To SoftLayer The Data Transfer Request was submitted by the user and the hardware is being shipped to the selected data center. 
 Received by SoftLayer The shipment was received by the data center, the device was assigned a serial number and was scanned into the IBM Cloud® system.