Foodbot – Sitecore Connect – A Recipe with a Custom HTTP API End Point

This is a second part in the series of articles exploring Sitecore Connect.

Setting the article Context:

Prev. we made use of available apps/actions listed in Sitecore Connect to create a recipe. In this article, we will see how we can create a recipe using a Custom HTTP Endpoint.

To make it interesting, we will create a FoodBot. As MVP 1 release, we will create a feature where user can interact with a MS Teams Bot -> Workbot and get preparation steps for a recipe of their choice. This time recipe here means food.

What we are gonna do?

• Create a recipe in Connect with a trigger from MS Teams Workbot. We will create a custom command with input parameter.
• We will use the input parameter in next step to make a GET call to a custom API End Point. As the topic in discussion is Connect, we will use a public free API (Tasty API Documentation (apidojo) | RapidAPI)
• Return a response.

And btw all this with no code.

TASTY:

Tasty is a free open source API. It can be accessed via Rapid API. It has several endpoints. One key end point is /recipes/list. It provides a data required to make a recipe.

Let’s get started.

• Create a new recipe with a trigger – New Command from Workbot for Teams “getrecipe” in our case.

• Define a input parameter. This is used to store the user input and it can be used in subsequent actions.

• In the Actions, select an HTTP Action and setup the connection. For Connection you can use different available authentication modes – Oauth/Basic/Head Auth or you can create your custom Authentication.

• For my case, Tasty API provided Header Based Authentication.

• Use the Recipe Name – Item Name input parameter configured in the trigger as query parameter.

• Setup the remaining like we did in the prev. article. And finally the recipe looks like below.

• Test/Start the recipe. Over to Teams.

Thoughts on Connect and Development Trends:

• Although, in an enterprise level this get recipe kind a Workbot won’t be required/used. The core idea I want to share via this article is, we would be required to expose contents via end point, rather than serving them as web page… We kind of already do that. With Layout Service/GraphQL etc. But we so far have exposed those end points to an application like a Front-End Head/Mobile App.
• So, what’s the difference, we usually have a code logic that renders a page/interface to user. Here after that part may be handled by some application that offers Front End components as templates and we can connect them to the content exposed by these end points.
• In fact, Sitecore XM Cloud Components is the best example of this.
• XM Cloud Components is a Front End as a Service feature. That allows you to develop renderings – presentation blocks on the fly with contents flowing in from any API/GraphQL End Point.
• Some additional info related to components can be found in our session in SUGCON EUROPE 2023