In this article, we're going to integrate a simple webservice to explain how webservices work and how the received data can then be used further. Webservices are a method to connect other environments to your own. By executing requests, you can retrieve data to process, store and show in your application. 

For this example, we use the JSONPlaceHolder API. It is specifically designed to perform requests for testing purposes. Information about the webservice other than what is discussed here can be found here: JSON Placeholder

At the end of this article you'll know:

The assignment we're making is divided in chapters as listed below:

First, we have to define the JSON Placeholder webservice in your Betty Blocks application. After this, we can create an endpoint so we can retrieve the data. Then we store this response in a custom model.

1.1 - Go to your Back Office and hover over the Tools button in the Builder bar. An additional menu will open. Click the Webservice button to open the platform's Webservice section.

1.2 - As you (probably) haven't created a Webservice yet, this overview is empty. Click on New (top left in your screen next to the play button) to add a Webservice.

A form will appear, which we are going to fill in. Enter the following values in the corresponding fields.

The Host is like a web address where we'll retrieve the information from. It's necessary to choose JSON as content types. If we don't do this, we wouldn't be able to execute an important step later on. Headers and Help text are not relevant for this assignment. It should look something like this:

Click Save  and you got yourself your first Webservice! It doesn't do much right now, so let's move on.

1.4 - To do the actual requests, we need to create a so-called Webservice endpoint. These endpoints point towards specific pages from the Webservice where in this case a set of data is served.

The right column of the Webservice we are viewing shows how many Webservice endpoints we have right now: 0. Click the + button to create an endpoint right away!
Another form appears, this time to define the endpoint.

Enter the following values in the corresponding fields:

The Name is basically a short description of the endpoint, describing what it is going to do. The Path is the location from which we are getting the data within the Webservice. As you can see, the Host and Path values work together to define the request URL we are collecting the data from. Leave the rest of the fields empty, as we won't be using them for now. Click Save  and you should have a form looking like this:

1.5 - These 2 components (a webservice and a webservice endpoint) were all we needed to do to execute a request. Click Run test to see if we did everything right.

A few things to take a look at:

1.6 - Time to shine some light on those Custom models: what are they and why are they awesome? This article will tell you all about it: What are Custom models? 

Click Generate custom model at the top of the form after running a test to generate a Custom model. A spinner will start as the Custom model is generating, followed by a confirmation message.

Click OK and an updated version of the endpoint will load. 

The Custom model will capture all received values in the designated attributes, which can then be easily assigned in Actions and UI webpages. It makes building a Webservice a lot quicker because you won't have to fetch every single value using text expression variables, which is more prone to mistakes made by the user.

If you thought that was a walk in the park and feel like you want another exercise, try creating some other endpoints. But this time, we'll send along some values to define what data we're going to receive and even create on the other server.

The first additional endpoint we're going to create enables us to get a single record, based on the id of the record. 

 Create another endpoint on the JSONPlaceHolder API and enter the following values in the corresponding fields:

As seen in the Path option, we're including a variable. Create a Path variable called id and make sure it's correctly added to the path.

Save it, press Run test and enter 1 as Id.
​This will get you a successful response, containing 1 record, with the Id 1. Great!

The second additional endpoint we're going to create enables us to get a set of records, based on the userId (which is an attribute within the data). 

Create another endpoint on the JSONPlaceHolder API and enter the following values in the corresponding fields:

This time, the Path option doesn't include a variable. Instead, we'll add a Query variable, which is automatically appended to the path.
Call it userId, same as the attribute in the data.

Save it, press Run test and enter 1 as userId. This will get you a successful response, containing all records containing the userId value 1. Great!

The third additional endpoint we're going to create enables us to send values to create a record on the other server.

Create another endpoint on the JSONPlaceHolder API and enter the following values in the corresponding fields:

We won't include variables or other dynamic values in the URL. Instead of requesting existing data, we're sending data to create something new. This is done with Body variables.
Create 2 body variables: title and userId.

Save it, press Run test and enter whatever you want in the variables. This will get you a successful response, showing you the recently created record. Great!

Note: Because of how the API is designed, it will not actually create a record and the id will always be 101. But it does react exactly how a 'real' Webservice would.
​

With the Webservice and endpoint in place, it's time to create an action so we can execute requests in a more user-friendly way, which can be applied in multiple sections of the platform. This also the first step to eventually store the retrieved data in our own data model.

2.1 - Go to the Action section of the platform by clicking on the Action button in the Builder bar. That should bring you to the following page.

2.2 - Because we don't have actions yet, this overview empty.

Click New in the top left corner to add an action. The action will use the newly created Webservice, so we'll give it a similar name. Enter the following values in the corresponding fields:

Leave Model blank, as we're not using it right now. We can also ignore the rest of the fields, as they're not relevant for this assignment. The action form should look something like this:

After clicking Save, the form closes, the visual action editor opens and it's time to add a step.

2.3 - Click the + between the Start  and End marker to add an event. Choose Http request as Kind and additional options appear. The JSONPlaceHolder webservice should be selected as default because it is the only webservice our application currently has. 

Note: If you created the additional endpoints earlier, make sure you select the correct endpoint: GET All Albums.
​
Basically, that's all there is, for now, you don't need to adjust anything in this event. After saving, it should look like this:

As you can see, you can even navigate directly to the Webservice and the Webservice endpoint from this event. The value at Response as defines the name for the variable in which the response is stored for the rest of the action.

If you created the additional endpoints earlier, make sure you also create additional actions which request those endpoints. For each webservice endpoint, create an action. Make sure you create variables to pass along the required values. Assign these variables in the Http request events.

That's the first part of the action that we're building. For the second part, we need to build a model in our Data model so we store the received data in our app.
​

In this assignment we will process the data from the web service response and store it in our application. A data model is required for storage. A model contains properties to store different parts of the received data. 

If you're still not entirely sure what the Data Model's purpose is, don't worry! We have a bunch of articles dedicated to them that should explain all you need to know, like this one: What is a data model.

After creating a model with properties, we will further extend the action from assignment 2. Finally, we will display the stored data from the response in our standardized Back Office user interface.

3.1 - Go to the Data Model section of the platform by clicking on the Data Model button in the Builder bar. That should bring you to the following page.

3.2 - Again, click New to add a new model. We're calling this model Album as it is going to hold the album date we receive from the webservice. The Help text isn't necessary, but feel free to enter a value.

Save the Model and click the + button next to Properties to open a new property form right away.

3.3 - The properties we're adding needs to correspond with the response of the Webservice requests. For this example, we'll add 3 properties:

Title

Typicode identifier

UserId

After saving a property, it should look something like this:

With our Data Model in place, it's time to connect it to the action we created earlier. 

3.4 - Go back to the action and click Edit to open the Visual Action Editor again. It still has 1 event, now let's add a second event: a Loop event.
Because the response we receive contains multiple objects, it is served as a collection. By adding a Loop event, we can go through each object within our response.

Click the + (after the Http request event) to add an event and select Loop as Kind. Here you can select the Response as variable from the first event as collection in the Through setting. The As variable then serves each object per iteration as an object variable, call this one album. After saving, the event should look like this:

3.5 - Within each iteration of the Loop event, an event where the object is saved needs to be executed. We can do this by adding a Create event, based on the Album model we just created. Assign the title attribute from the Loop object to the title property and click Save. The event should look like: 

3.6 - With the Loop and Create event in place, the action is done for now and should look like this:

To sum it up: 

Do not execute the action yet, though. That comes later!
​
​3.7 - The model and property we added earlier are used for storing the received data. To view the data, we need to design our Back Office interface. Thanks to Betty Blocks, this should only take a minute or so with minimal effort.

Go to Back Office and turn on Builder Mode with E. The Back Office should still be quite empty, only show you an empty Manual. Press the + Add grid button as shown in the image below and a popup will appear.

As seen below, the settings will be pre-filled with the first model it finds. The Use options refers to a layout in which the columns are arranged. If this is the first time adding a grid for that specific model, stick to - New - and click Save .

After pressing Save , a grid is automatically generated including all available columns in alphabetical order. Stop Builder mode by clicking E on your keyboard and make sure the Back office looks like this:

3.8 - Fine, let's kick that action off and see if everything worked out.
Go back to the action and look for the green button saying Run. This will trigger the action manually. If everything went according to plan, you should get a Success notification.

Dismiss the notification and go back to the Back Office. The Album view we added before should contain data now!

Alright! We created a Webservice, an action that uses the Webservice and added a model in which the data is saved. As the last step in this assignment, we're going to create a Page in which the data is retrieved from the Webservice on each pageload and then shown in table.

4.1 - Go to Pages and click + New page  in the top-left corner.

After the modal opens, choose UI builder. This will make it super easy to make a data table.

To get a simple but dashing look, choose Header, footer, left nav  as Layout.  

Choose Blank page as Content.

Finally, enter albums as Path value. This means the webpage will be shown when going to https://*yourapp*.bettywebblocks.com/albums . The *yourapp*  part needs to be replaced with your own app url, of course.

Click Finish in the bottom-right corner and you've got yourself your first page!
​
The page will generate, showing you 2 main components of the UI Builder;
The Palette and the Canvas. As if we’re painting. 

The Palette holds your paint; all components provided by Betty Blocks for you to configure your pages and even components you can build yourself.

The Canvas shows you the beauty you’re creating; all components you applied to the page, showing the structure of your page.

4.2 - Before adding any component, we're going to create an action.
The thing with webpages and action is that action are always executed before the webpage is loaded. That means we can execute the Http request event like in our action earlier and use the retrieved data to load in our webpage.

Go to the page settings by clicking the third tab in the Pallete and click Open action.

This will enable an action that is executed each time the webpage is loaded. Also, the action itself will open, allowing you to add events to the action.

The next step is basically the same as what we did in the other action:

Boom. Action on webpage, done. Now we only need to include the response in our webpage. 

4.3 - Take a look at the variables on the page. Click on the second tab in the Pallete.  It should contain at least 1 variable, called item, under the section ACTION VARIABLES. This variable contains our response in a Collection (custom model).

Bells should start ringing now! If not, no worries, we got this.

4.4 - Go back the Design tab (first one) in the Pallete and search for "dynamic table".
Drag the Dynamic table component to your canvas and make sure it sticks. A blue line in the Page container should show. Release the component to see 2 columns appear in the Dynamic table component.

Open the Object Tree (fourth and last tab in the Pallette).
Double-click on Dynamic table to open its settings. Click on the Data icon and click on the blue variable button (chain-link icon) to select a variable for the Dynamic table.

Select the variable from the action as Collection for the Dynamic table.
To make this a bit more clear, enter album in the Object name setting.

By doing these last steps, we've set the received data as content for the table. Now we need to sort the data so each piece of information is shown in the correct place.

4.5 - Each object within the Dynamic table has been made available through the album variable. Therefore, we're using that variable in each Dynamic table column.

Click on the first [select a variable] to set one of the custom model's attributes as content in the fourth tab of the component. A variable browser opens with the album variable pre-selected. You just need to choose one of the attributes. Click on userId and then Select (or double click on the attribute).

The attribute is then set in that specific column. Repeat this process for the other column, but then for the attribute title. 

4.6 - Add an extra column to the dynamic table by clicking the dynamic table in the Object Tree and adding a child component. This is done by clicking the + button.

Same as with the other columns, select an attribute from the album variable. This time, choose the Id attribute. Your table now has 3 columns, looking like this:

4.7 - Time to try it out now! By clicking the Play button, a preview of the page is loaded. This will however still trigger the action on the page so we can see how the received data is parsed in our table. Depending on the length and complexity of a page action, a pageload can take longer.

With the received data parsed correctly, this should be the desired outcome:

Same as with actions, if you created the other webservice endpoints, you can also create additional pages that use them. Create input variables on the page and assign them in the action when requesting the webservice. 

Kapow! We've done some pretty cool stuff, right! And it wasn't event that hard. Let's go through the assignment and what we've done now:

Now that's progress! These were just the basics, the tip of the iceberg. There is so much more to learn, as each webservice is different and requires a different set up.