search

Latest posts


One of the cool new features in Watson Conversation in IBM Bluemix is the ability to support a global audience by creating language specific versions of your bots. In this blog post I will give you some best-practices for creating bots in other languages.

To create a bot in a language other than English simply select the language from the pulldown for your workspace as shown below.

Select Watson language

Select Watson language

Now that you have your workspace configured for your desired language you can start creating the intents and entities.

When you create your intents you need to avoid using message fragments. You should create complete sentences. For example, in my Spanish insurance bot I use the complete sentence “Localizar mi póliza” rather than the message fragment “Localizar mi” as shown below.

Watson intents

Watson intents

It is important to use complete sentences for Watson Conversation’s training engine to work correctly. You may be asking yourself at this point if you need to create a separate sentence for every synonym of “póliza”. The good news is that this is unnecessary. You simply list all the possible synonyms associated with “póliza” on the entities screen. So in my case I defined a few synonyms for “póliza” as shown below.

Watson entities

Watson entities

When you define your conversation nodes you simply indicate the intent and entity to use in the dialog. In my case I set my node to use the #policy-information intent combined with the @policy entity as shown below.

Watson dialog

Watson dialog

I hope this post helps you quickly get going with creating multilingual conversational bots using Watson Conversation.


With the recent arrival of Watson Conversation on IBM Bluemix, developers are wanting to generate very sophisticated conversational bots that need to collect input and record state. In this blog post I will show you how to accept input in a conversational dialog and record state changes in your conversation.

After you have created your intents and entities in Watson Conversation you will want to start to create your dialog. The first question that developers immediately ask is how do you capture and then record the input of the user? To do this create a dialog node with a new condition called input.text as shown below.

Dialog with input.text condition

Dialog with input.text condition

This node will record the user input and make it available as input.text. If you want to echo this input back to the user then you can use simply surround the condition with <? and ?>. So in this case we would use <? input.text ?> to repeat the input back to the user.

Now what do we do if we need to return the input value back to our calling application. How do we return the value? To return the input we will use a context object. To create a context object, switch to the “Advanced” view in the node by clicking on the three vertical dots in the right corner of the dialog node as shown below.

Advanced Node View

Selecting advanced node view

After you have the “Advanced” view displayed you will want to maximize the view by clicking on the “Maximize” button to make it easier for you to create and edit the JSON object as shown below.

Maximize Node

Maximize node

Now add a section called context as show below in the editor and select a field name that you will use to refer to the input.text. In this particular case I created a field called policy and return the value that was input by the user. From your calling application you can simply access the policy field from the context object that is returned by the Watson Conversation API.

Advanced view

Advanced view

Now what happens if you need to refer back to your input.text later in your conversational dialog in one of your nodes. How do I access one of the fields from the context object? To do this let’s open up a maximized view of one of your nodes that needs to access one of your context fields as shown below.

Accessing context variables

Accessing context variables

As you can see, you can easily reference your context variable by preceding the context variable with a $. So in this case I access my variable through $policy. You will immediately notice that in the editor I have nothing in my context object and this is ok, as the context object I will be accessing is the one being used at run-time that was passed back to Watson Conversation through the API from your calling application. If I want to add more context variables I can do that at any time by simply adding more fields to the context object. Keep in mind that you can also replace existing fields by simply updating their values in the context object.

I hope this short post has helped you understand how to capture user input and carry state in your Watson Conversation bots.


One of the great features of the IBM Globalization Pipeline service on Bluemix is the ability to select the machine translation engine you want to use to translate your applications. This gives you great flexibility to choose the engine that gives you the best results for the type of application you are translating. Currently, you can select from both Watson Language Translation and Capita TI SmartMATE. In this short video I show you how you can quickly configure Globalization Pipeline to use Capita TI SmartMATE.

 


One of the biggest challenges with using cloud services is having to learn all the RESTful APIs that a service provides. Developers really want to be able to quickly integrate the use of a cloud service into their application without having to spend a lot of time studying a service’s Swagger docs. With the recent launch of the Globalization Pipeline service on IBM Bluemix the development team has made it very easy to get started with integrating the service into your application. The Globalization Pipeline service provides several open source SDKs in several programming languages such as: Java, Node.js, Python, and Ruby as well as plugins for Apache Cordova.

In some cases all you need to do is drop the SDK into your build and you are on your way to using the service. For example, if your application is a WebSphere Liberty application using Java 8 running on IBM Bluemix all you need to do is drop the SDK’s jar file into the extensions directory. Once you have included the jar file, then your application will automatically connect to the Globalization Pipeline Service without you having to even make any changes to your application code.

When it comes to mobile applications the SDKs have you covered here as well. You can easily include the Apache Cordova plugin in your mobile hybrid application and simply specify the Globalization Pipeline’s service credentials and then you are able to start using the service without having to directly make all the RESTful API calls yourself.

I hope this post helps you quickly get started with using the SDKs for the Globalization Pipeline service on IBM Bluemix.


I am thrilled to inform you that IBM Globalization Pipeline for Bluemix is now generally available on IBM Bluemix.

Using the IBM Globalization Pipeline service on Bluemix you can quickly translate your applications running on Bluemix into other languages while continuing to work within your DevOps/Continous Delivery infrastructure. The cool thing about using the Globalization Pipeline service is that you get to leverage the power of machine translation for rapid turnaround combined with the ability to make custom edits. Using the service is a snap especially when you utilize the service’s open source SDKs. In some cases, for example, the Globalization Pipeline SDK for Java, you don’t even need to make any changes to your source code to connect your application to the Globalization Pipeline service — simply recompile your app and deploy it on Bluemix and you’re ready to go.

Once your application is connected to IBM Globalization Pipeline, any translations that you request or edits to translations that you make, will be immediately available to your application. This means that you don’t need to recompile, repackage, redeploy, or even restart your application to see your translations. To learn more about the Globalization Pipeline service and see it in action checkout these videos.

 


This blog post is to let you know about some exciting news out on the IBM Bluemix Garage Method site. For those of you not familiar with the Bluemix Garage Method. The Bluemix Garage Method is all about digital transformation through rapid innovation and DevOps. The Bluemix Garage method gives you recommended methods, practices, tools, and insightful experiences to harness DevOps.

Now on to the breaking news!! Globalization is now part of the IBM Bluemix Garage Method. There are two new articles for you to take a look at that cover Integrated Globalization and the exciting Globalization Pipeline service on Bluemix. These articles explain how to incorporate globalization into your overall DevOps processes and show you how to break free from the old siloed model of translation where you have to sit around and wait for translation.  So go and check out the articles and start building global cloud applications.


Many developers may be surprised to learn that services from IBM Bluemix can be called from environments other than IBM Bluemix. In this blog post I am going to show you how you can call the IBM Globalization Pipeline service on IBM Bluemix from Amazon Web Services (AWS) Lambda. So let’s get started.

 

  1. Create an instance of the Globalization Pipeline service on Bluemix and don’t bind it to any application.

    Unbound Instance of Globalization Pipeline Service

    Unbound Instance of Globalization Pipeline Service

  2. Copy the service url and instance id from the Service Credentials tab. We will use these values later when call the RESTful APIs.

    Service Credentials

    Service Credentials

  3. Click on the Manage tab and then select the Users tab from the Globalization Pipeline service’s dashboard and create a New User. Create a user called reader and make the type reader with access to all bundles.

    Globalization Pipeline User

    Globalization Pipeline User

  4. Click Save and then copy the User Id and Password. We will use these values when we call the RESTful APIs.

    User ID and Password

    User ID and Password

  5. Create a resource bundle in the Globalization Pipeline service and translate it into as many languages as you like. Here is a link that shows you how to get started with the Globalization Pipeline service.
  6. Download my sample code and fill in the values for the service url, instance id, user id, and password in the index.js file.
  7. Create an AWS Lambda function on the AWS console and upload the zip archive that contains your modified source code. Here are links that show you how to create AWS Lambda functions.
    Lambda Configuration

    Lambda Configuration

    Upload Lambda Code

    Upload Lambda Code

  8. To test your Lambda function create a test event and use a JSON object that contains the name of your bundle and the language that you translated your bundle into.
    Input Test Event

    Input Test Event

    Sample Output

    Sample Output

    That’s all there is to it. As you can see it is pretty easy to call a Bluemix service from other environments including other clouds.


In this post I am going to help you overcome some of the issues you might encounter when trying to output Unicode from OpenWhisk actions. In a previous post I showed how to call the Globalization Pipeline service from Node Red and in this post I will show you how to call the Globalization Pipeline service from an OpenWhisk action and properly handle Unicode text that is returned by the service in OpenWhisk. If you are already familiar with how to get the Globalization Pipeline service’s credentials then you can go ahead and grab the service instance id, username, password, and create a reader key for accessing the service. If you don’t know how to do this, then read my earlier post.

I have provided a sample OpenWhisk action JavaScript file that shows how to call the Globalization Pipeline service. Feel free to download this file and simply insert your credentials in the appropriate locations. You will notice that we don’t simply return the raw result returned by calling the Globalization Pipeline service, but rather we first URI encode the messages for each key. We need to do this, because OpenWhisk converts all output to the ISO8859-1 encoding that causes Unicode characters beyond U+007F to be incorrectly converted. To avoid this issue we convert the messages to a safe URI encoding before outputting them by calling the querystring.escape function. This means that you will need to decode the messages before using them in other JavaScript functions. To decode the messages in JavaScript you can use the decodeURI function.

To upload the OpenWhisk action from the command line use the wsk action create command.

wsk action create globalization g11n-pipeline.js

To invoke the OpenWhisk action from the command line use the wsk action invoke command and substitute the lang id and bundle name with your values.

wsk action invoke globalization –blocking –result –param lang ‘lang id’ –param bundle ‘bundle name’

I hope this post helps you with using Unicode text in OpenWhisk.


This post is going to be based upon a previous post and video that I made that shows you how to quickly build an API with IBM API Connect, Node Red, and Cloudant. In this post we are going to actually create the same API, but instead of using Node Red for our internal API implementation we will be using OpenWhisk from IBM Bluemix for our internal API implementation. OpenWhisk is IBM’s new event driven compute technology for serverless computing that hides the existence of servers from developers. Serverless computing allows you to simply provide the code you want to be executed without having to worry about creating any servers to run your code. If you would like to see short video on how to do this checkout the video on YouTube.

So let’s get started by creating two actions that will connect to Cloudant and then format the response. Here is the code for calling my map/reduce view on Cloudant and here is the code for formatting the response from Cloudant.

Let’s first create an OpenWhisk action called summary for accessing my map/reduce view on Cloudant.

wsk action create summary summary.js

Now Let’s create an OpenWhisk action called formatter that formats the response from calling our map/reduce view on Cloudant.

wsk action create formatter formatter.js

Once we have our two actions defined we can chain them together into a new action called claims so that the output of the summary action becomes the input for the formatter action.

wsk action create claims –sequence summary,formatter

Now we will create an API on API Connect that will call our OpenWhisk chained action. In API Connect all we need to do is to invoke our action by using the OpenWhisk RESTful API endpoint for our action. The endpoint for accessing your action is based on the following pattern:

https://openwhisk.ng.bluemix.net/api/v1/namespaces/{your namespace}/actions/{your action}?blocking=true

So all you need to do is to replace {your namespace} and {your action} with your specific values for your OpenWhisk installation. You will also need to obtain your OpenWhisk username and password that will be needed to call the RESTful endpoint. You can find your OpenWhisk username and password from the OpenWhisk Configure CLI page. Here is a screenshot showing where you can find that on the page.

OpenWhisk CLI Page

OpenWhisk CLI Page

Once you have created your API on API Connect go to the assemble page and edit the invoke action to call  your OpenWhisk action sequence. Be certain to include your OpenWhisk username and password and set the HTTP method to POST. Here is a screenshot showing where to insert the values.

Invoke OpenWhisk Action Sequence

Invoke OpenWhisk Action Sequence

At this point simply publish your API to IBM Bluemix just like you would for any other API. That’s all there is to it. Now you have an API running in the cloud without having deployed any server to run your API.


In this post I am going to show you how easy it is for you to create a Bluemix tile for an API that you created using IBM API Connect. When you create APIs with IBM API Connect the credentials and urls for accessing your services are published in the developer portal that is tied to the catalog that you used to publish your APIs. Now what happens if you don’t want to embed or create special environment variables to store your credentials for your application, but instead want to use the VCAP_ENVIRONMENT variable to hold the credentials. Fortunately you can create a CloudFoundry user provided service that contains the credentials for accessing your service. This enables you to access the credentials just like you would any other Bluemix service. To do this all you need to do is to use the cf cups command. Here are the steps:

  1. Copy your API’s URL, client_id, and client_secret from the developer portal tied to your catalog. You can find this information from the “API Products” and “Apps” tabs from the developer portal as shown in these screenshots.
    Application Credentials

    Application Credentials

    API URL

    API URL

  2. Run the cf cups command from your command line and pass in the parameters as shown below where you substitute your values for: API-NAME, ID, and SECRET.

    cf cups API-NAME -p ‘{“url”: “API-URL”, “client_id”: “ID”, “client_secret”: “SECRET”}’

  3. From the Bluemix dashboard bind your service provided instance to any of your Bluemix applications. Once you bind the service you will be able to see the credentials from the Bluemix dashboard and your application will be able to access the credentials through the VCAP_ENVIRONMENT variable as shown below.

    User Provided API

    User Provided API

As you can see it is pretty simple to publish your API’s credentials to any application on Bluemix.


‹ previous posts next posts ›
close
search
Latest Tweets

Hi, guest!

settings

menu