 Hi, I'm Dave Salser from BMC Software, and today we're going to show how to use the direct REST API integration capabilities in Innovation Suite to extend Helix Chatbot. When you're working with an Innovation Suite application, users interact with it various ways. The data is often stored locally with Innovation Suite. But if it's stored somewhere with a REST API availability in the back end, whether it's Remedy running with a REST API on ITSM or a special integration gateway you already have set up or a public internet API like AWS, you want to be able to get to it in a simple way. REST API is for that command line of the cloud. A full solution will often involve a mix of cloud-based services. And you need one way to get to them that doesn't involve complex setups and additional infrastructures. You need to be able to deal with complex data types, often defined as JSON. You want to extend your solution rather than modify it to make upgrades easy. And above all, you don't want to have to write code to do it. Let's take an example using BMC Chatbot. Let's say that you have a dialogue where users can ask for a time off. But you want it to take a different path if the user doesn't have any time off accrued. However, let's say the accruals are stored in JIRA, which is a public web service. You want to do this codelessly and have different paths depending on what happens. If you look in JIRA, you can see in this example that the accrual records are stored as JIRA tasks with a pair of labels. One that says PTO accrual and one that says the user's name. The description field is where the actual time off is accrued. You can see that this object has no time off accrued. So when Alan requests time off, the Chatbot will pull up this information using the JIRA integration and tell him he has two days accrued. And then it proceeds to the standard dialogue that was generated using our out-of-the-box wizard. So far, so good. However, remember that Amit had no time off accrued in his JIRA task. So in this case, the interaction will go differently. After Amit asks for time off, it will tell him you don't have any time off. You'd better speak to your manager. So how was this done? The design of the standard part of asking is the same for all conversations where you're requesting a service from Digital Workplace Catalog. In this case, we've extended it. The first step is to look at how the JIRA interface works. You will need to understand the JIRA, the REST API, as it's documented on the JIRA site, both the inputs, the parameters, and the resulting document returned by the REST API. Next, we'll create the necessary definitions in Innovation Studio. We'll put these in a helper library called REST integration. This way we can reuse our JIRA integration for other use cases if we decide to later on. First, we need to define the document structure that will be returned by the REST API. This is a new reusable object that's very handy in Process Designer for looking at individual parts of a response or something you send through an API. The API collection itself has a search API where we define the parameters that JIRA expects, as well as any headers, and we can define the document that we expect to get back. Our process to call it, it's very simple in this case. We're simply calling the search API and we define enough of the parameters that can be used in a flexible way. How many records to return, what the JIRA query is, that kind of thing. Now this becomes a reusable building block for any type of JIRA REST API integration that you might wanna do in Innovation Suite. Since that's a little cumbersome to use for this use case, we'll create another helper process. This one takes the two labels as inputs. It generates the query, it specifies, you only want one result back, and then it takes the result list and dereferences the first item in the list to return a single JIRA issue as its output. This will make it a lot easier for applications like Chatbot to get exactly one record back. Now we're gonna design the actual process that will be called by Chatbot. So we put this in another helper bundle called ChatHelper, could have been in the Chatbot bundle actually. We define the parameters that the Chatbot will need to know about. The input parameters such as the username and the source, that way we can track who is asking. And then we can return things like was it found? And we can return the accrual number itself. These will wind up being context variables on the Watson side so that the flow can use that information. We call our helper method, which will return the list object. Not shown here would be additional logic you could add to handle cases where there was nothing found. Now we can pull out the individual item we want from that response document, such as the accrual number. We can return those as output parameters. We can add some additional logic if we want to here, which I won't show in this video. Now comes the time when we need to customize the Watson conversation in Watson Assistant itself to use this. Note that the out of the box dialogue node handles the PTO intent. We can create another node above it in the list with the same intent. Essentially it intercepts the request for time off. We customize the JSON to include the binding to that special process we just created. We pass in the input parameters like username and source. And then we make sure the outputs of the process are mapped to context variables as well. We specify the fully qualified process name to call. And we specify that the chatbot should wait until the process concludes before returning the response to Watson Chatbot. How those context variables are used depends on the child nodes. The first one handles the case of no cruel found. And after displaying a message, it simply jumps to anything else I can help with. The second node will handle all the other cases where there isn't a cruel found. It displays the cruel context variable so the user knows how much they have accrued. And then it jumps into the standard time off dialogue which you don't have to touch. Integration service is still available for cases where you can't use the REST API or you want to do other capabilities such as go behind the corporate firewall. For pure REST API integration, however, it is no longer needed. To recap this, all applications built in innovation suite can use this capability now of integrating directly with REST APIs. There are new definition objects to support it. And applications can be extended by basically adding behavior to processes, records and views without customization or upgrade woes. Thanks so much for watching. And as always, please get more information from developers.bmc.com.