Hello again community. I received great feedback from some colleagues and on the online posts about my previous blog about #NoCode or #LowCode tool #AppGyver, you can read about it here. To read this blog in spanish leelo aqui
Today, I am going to try to show a Master detail scenario where the application retrieves data from an AWS REST API endpoint. Assume we have access to a REST API running under the AWS API gateway service. We are going to retrieve a list of Tickets for a Master Detail scenario. In AWS, I had to build a Lambda function using NodeJS, and an AWS API gateway calling the Lambda function. At a 10,000 step view of the backend, assume the AppGyver app will be calling a REST API and it will get data. Very simple!
Let’s open the app builder to create a new project. I called it MasterDetail. I started from the default page to include a table or list. I did not find a table control on the list of components in the left nav. After reading a tutorial, I figured out, AppGyver allows you to install additional controls that are not included by default. Go to the Component Market (search box under the CORE tab) to look for a table or a list control to be used within our Master view. At first sight you may think it may be the same behavior on either option. Personally, I prefer the basic list view due to it has the carrot at the end of each row, therefore, it gives me the impression that I can click it and drill down into the detail page.
Once you select the type of control you want to use, you will need to install it by clicking the “Install” link. If it gets installed properly, then the control will be displayed in the INSTALLED tab.
Let’s configure our DATA resource so that we can leverage the AWS REST API we mentioned before.
Select REST API direct integration from the menu below.
Provide the details to identify the resource and the URL to access the endpoint
Since we are retrieving data directly from the resource, there is no need to set any entity name in the relative path input field below.
Once you set up the GET COLLECTION (GET) method, proceed to the TEST tab and see if data is retrieved. BAAAM! We have data.
When using the typed data, I was not able to set the selected item and the non-text values were not being displayed on my app. I will explain a little more later in the blog. I had to change all my json properties to string on the data source side (AWS Lambda). Ideally, this control should be able to recognize the data types and be able to show them. Even when I tried parsing the properties using the STRING function, I was still unable to show the values in the application.
After fixing the data types and re-setting the schema, you can see the text fields are integer text and numeric text. Using this type of text allowed me to set up and show the additional properties in the basic list.
After setting up the data and its schema, go back to the canvas and drag and drop the Basic list control into it.
On the PROPERTIES tab, select Configure to add the data we have integrated to in the previous step.
Select the X to go into the Data Resource selection window.
Select Data resource
Select one of the available data sources
Populate the list control properties based on your data source properties. You must match the control data types otherwise your data will not show visible on the screen. Below I tried parsing two of my numbers to string type so that I thought they would match and show on the data preview, however, that did not work. At this point is where I changed the data types in the data source side.
Until this step was done, I was unable to see the data but now I am able to see the data in the data preview list.
After setting up your control, launch the application to test it out. Notice I added an alert function to see if the selected item would return its id from the data source and it does indeed!
Now that I can select the item and I am able to capture its id, I am going to add navigation from the Master page to the Details page. My detail page contains a simple label and a button to simulate the navigate back to the master page.
Below are images that show the dynamically passed id from the master page into the details page – well done AppGyver.
Finally, I would like to describe the reason to add the button in this page. The button would trigger a press event and within this button, I wanted to show a confirm alert so that the user can select Ok or Cancel. The logic for this button is also built with #NoCode #LowCode and it looks like the following
The button Component tap event calls a confirm dialog and it is used to ask the users about an if type of logic. There is one input flow and 2 outputs from the selection of the confirmation message.
The first output is the yes/ok/confirmation which in my case, I used to execute additional navigation and send the user back to the master page. Other scenarios here would be to do a post / save and then navigate back.
Since I do not have any logic to execute when the user selects cancel, then I do not need to include any logic in that branch of the execution.
What I liked in this example:
What I believe needs improving:
My closing thoughts:
During this exercise, I was able to quickly create pages and navigation between them. I enjoyed being able to install additional components that were not available by default. I think it was simple to understand and add the branching logic (if) that I added to the button control. The difficult part during this blog was not being able to quickly understand where the undefined values were coming from until I changed the data types in the REST API to all be of type string. I believe this probably needs a little enhancement from the tool point of view due to the schema being also set up within the tool. The event properties and the event input/output when selecting on the list were not as bad as I initially thought would be during set up. Finally, I think the logic to build this type of application is straight forward starting from a master list and drilling down into the details page. I intentionally did not do another GET request in the details page because I already had the id I needed so I leave that additional GET request to the reader of this blog. What was your favorite part of this example? What are other scenarios you would like to explore, share, or recommend for the community. Thank you for reading and enjoy your weekend.
Today, I am going to try to show a Master detail scenario where the application retrieves data from an AWS REST API endpoint. Assume we have access to a REST API running under the AWS API gateway service. We are going to retrieve a list of Tickets for a Master Detail scenario. In AWS, I had to build a Lambda function using NodeJS, and an AWS API gateway calling the Lambda function. At a 10,000 step view of the backend, assume the AppGyver app will be calling a REST API and it will get data. Very simple!
Let’s open the app builder to create a new project. I called it MasterDetail. I started from the default page to include a table or list. I did not find a table control on the list of components in the left nav. After reading a tutorial, I figured out, AppGyver allows you to install additional controls that are not included by default. Go to the Component Market (search box under the CORE tab) to look for a table or a list control to be used within our Master view. At first sight you may think it may be the same behavior on either option. Personally, I prefer the basic list view due to it has the carrot at the end of each row, therefore, it gives me the impression that I can click it and drill down into the detail page.
Once you select the type of control you want to use, you will need to install it by clicking the “Install” link. If it gets installed properly, then the control will be displayed in the INSTALLED tab.
Let’s configure our DATA resource so that we can leverage the AWS REST API we mentioned before.
Select REST API direct integration from the menu below.
Provide the details to identify the resource and the URL to access the endpoint
Since we are retrieving data directly from the resource, there is no need to set any entity name in the relative path input field below.
Once you set up the GET COLLECTION (GET) method, proceed to the TEST tab and see if data is retrieved. BAAAM! We have data.
When using the typed data, I was not able to set the selected item and the non-text values were not being displayed on my app. I will explain a little more later in the blog. I had to change all my json properties to string on the data source side (AWS Lambda). Ideally, this control should be able to recognize the data types and be able to show them. Even when I tried parsing the properties using the STRING function, I was still unable to show the values in the application.
After fixing the data types and re-setting the schema, you can see the text fields are integer text and numeric text. Using this type of text allowed me to set up and show the additional properties in the basic list.
After setting up the data and its schema, go back to the canvas and drag and drop the Basic list control into it.
On the PROPERTIES tab, select Configure to add the data we have integrated to in the previous step.
Select the X to go into the Data Resource selection window.
Select Data resource
Select one of the available data sources
Populate the list control properties based on your data source properties. You must match the control data types otherwise your data will not show visible on the screen. Below I tried parsing two of my numbers to string type so that I thought they would match and show on the data preview, however, that did not work. At this point is where I changed the data types in the data source side.
Until this step was done, I was unable to see the data but now I am able to see the data in the data preview list.
After setting up your control, launch the application to test it out. Notice I added an alert function to see if the selected item would return its id from the data source and it does indeed!
Now that I can select the item and I am able to capture its id, I am going to add navigation from the Master page to the Details page. My detail page contains a simple label and a button to simulate the navigate back to the master page.
Below are images that show the dynamically passed id from the master page into the details page – well done AppGyver.
Finally, I would like to describe the reason to add the button in this page. The button would trigger a press event and within this button, I wanted to show a confirm alert so that the user can select Ok or Cancel. The logic for this button is also built with #NoCode #LowCode and it looks like the following
The button Component tap event calls a confirm dialog and it is used to ask the users about an if type of logic. There is one input flow and 2 outputs from the selection of the confirmation message.
The first output is the yes/ok/confirmation which in my case, I used to execute additional navigation and send the user back to the master page. Other scenarios here would be to do a post / save and then navigate back.
Since I do not have any logic to execute when the user selects cancel, then I do not need to include any logic in that branch of the execution.
What I liked in this example:
- Able to install additional controls from the Marketplace
- Fast and easy way to set up navigation
- Able to accomplish the branching logic without having to write code. My initial thought was that I had to code on the alert or the confirmation dialogs
What I believe needs improving:
- Tool should be able to recognize the data types from external source and not show up undefined
- There should be a way to create variables from where we setup control properties without having to go click on the Variables toggle button
My closing thoughts:
During this exercise, I was able to quickly create pages and navigation between them. I enjoyed being able to install additional components that were not available by default. I think it was simple to understand and add the branching logic (if) that I added to the button control. The difficult part during this blog was not being able to quickly understand where the undefined values were coming from until I changed the data types in the REST API to all be of type string. I believe this probably needs a little enhancement from the tool point of view due to the schema being also set up within the tool. The event properties and the event input/output when selecting on the list were not as bad as I initially thought would be during set up. Finally, I think the logic to build this type of application is straight forward starting from a master list and drilling down into the details page. I intentionally did not do another GET request in the details page because I already had the id I needed so I leave that additional GET request to the reader of this blog. What was your favorite part of this example? What are other scenarios you would like to explore, share, or recommend for the community. Thank you for reading and enjoy your weekend.
- SAP Managed Tags:
3 Comments
