There is quite a discussion about the differences between no-code and low-code. Sure, low-code allows developers to add code, if visual developing just doesn’t do the job anymore. With no-code you might just get stuck or need another product, that solves the problem with your first product. The discussion is also about if no-code is just a part of low-code. In my opinion that is just the case. While others say both technologies have nothing in common, I tend to say they are very close, if not even related directly. That’s why I’m taking a look at both.
The other day I gave a lecture about “Portals and Integration of 3rd-party systems” at the University of applied science in Offenburg, Germany. That’s also the university I studied at. One part of the lecture was a hands-on exercise. And even though I was supposed to show the benefits of the low-code portal platform Intrexx, I afterwards realized, that the exercise didn’t include any coding. I accidentally showed the students, how cool no-code can be.
But let’s start at the beginning.
So what was the plan? The plan was to build a customer-dashboard. Since we usually don’t build a new CRM with Intrexx, one requirement was to use external data as the base of this dashboard. For this I used the Northwind service offered by the OData Website.
A second requirement was, that I wanted to not only show data from this OData service, but also data from inside the portal. Both data-sources should not depend on each other, but still be connected somehow.
So let’s do this!
Integrating the OData service
First things first. Since the external data is the base of this whole exercise, I first needed to establish the connection between my Intrexx portal and the OData service. For this, Intrexx offers an integration module, which is able to consume OData services.
So I add an OData service with this URL https://services.odata.org/V2/Northwind/Northwind.svc
That’s it for integration. Usually 3rd-party systems need authentication as well, but this doesn’t. It does require SSL though.
Building the dashboard
The second step is to create a new application for the dashboard itself.
Since I don’t want to have a dashboard that gives me an overview over all customers, but a dashboard that shows me specific data of one customer at a time, I need following elements:
- several pages beneath the customer-datagroup
- the dashboard-page, that contains a portlet-container
- an address-page, which will be marked as portlet
- a contact-page, which also will be marked as portlet
- an overview page that simply lists all customers
The customer-datagroup connects to the Customers collection of the OData service. I add all data-fields to the datagroup, so that I can use them afterwards, wherever I want to use customer-data.
After that, I add a new viewpage and call it “Customer Dashboard”. To this page I add two viewcontrols, one connecting with the CustomerID and the second connecting with the CompanyName. I then select both and group them as a heading.
Now I add the portlet-container to this page. This container will later hold all portlets. It also decides which portlets are allowed to be added to this dashboard. To this portlet-container, I add the parameter CustomerID and pass along the CustomerID parameter this page receives per default. This way every portlet that is called by this container will receive the ID of the customer that is currently shown in the browser. This is very important in order to keep the context! The parameter also enabled portlets, which require a parameter CustomerID. Before adding this parameter to the container, these portlets were hidden to the user and therefore couldn’t be added to the dashboard. I also mark the option to allow portlets of all applications from inside the portal.
Having the dashboard ready, I need some portlets to show as well. For this I add a viewpage “Customer Address” and add all address-datafields to it, using viewcontrols. The second page I add, is a viewpage called “Customer Contact”, where I add all datafields containing contact information. I mark both of these as portlet.
To open the dashboard in the browser, I need some link heading for it. For this I add an overview page to the application which simply contains a viewtable. Usually I would add a free-layout table because it creates a nicer result, but for now I don’t want to invest a lot of time styling every last part of the app. The viewtable contains the datafields CompanyName, City and Country. I mark the CompanyName as link, selecting the dashboard-page as the link-target.
Now I publish the application and test it in the browser. Nice huh? And only took me 20 minutes.
Adding a ticket-portlet to the dashboard
The address- and contact-information is already quite nice, but of course, it’s too little to call it a dashboard. So want to add something, that belongs to the customer.
For the lecture I wanted to build a small support-ticket application. What do I need for that?
- ticket-edit-page beneath the ticket-datagroup
- overview-page that only lists tickets of a certain customer
For this demo I added a ticket-datagroup, containing only datafields for the title, description and the CustomerID. The edit-page received an editfield for the title, a textarea for the description and a drop-down-control for the CustomerID. I add a parameter “CustomerID” to the page, which is not a required parameter and can only be used when creating new records. This parameter then becomes the default for the drop-down-list.
The last part is the overview page that lists only tickets of one customer. I call it “Customer Tickets” and add a parameter to it, with the name “CustomerID”. It is a required parameter, because the logic of the page won’t work without it. I mark the page as a portlet and make it available to all applications. After that I added a viewtable, listing tickets. To this viewtable I added a filter, comparing the CustomerID of the datagroup, with the CustomerID parameter of the page. I also add a button to the page saying “New Ticket”. The button opens the edit page as a tooltip and passes the CustomerID from the overview-page to the edit-page.
Now I publish the application and again switch to the browser. I don’t bother testing the ticket-application and directly head to the customer-dashboard. There I add the new portlet “Customer Tickets”. I’m also able to create new tickets for the customer I selected by clicking on the button “New Ticket”.
Though this was only a small demo for a lecture, it was a scenario that could happen in real life. Of course, not using the Northwind service from OData. It took me around 30 minutes to build this. And not a single line of code! Too fast for the students, but since the session was recorded they can review it as often as they want.
There are several things that are quite nice in this example, but they don’t strike the eye directly.
When you build software there are certain key principles you should keep in mind. One of it is the Principle of Least Knowledge(or Law of Demeter), another would be the Separation of Concerns(SoC). Basically they say: “Don’t mix up stuff, that doesn’t belong together” and “the less you know the better”. In this example, I add a ticket-portlet to a customer-dashboard. This mixes things up already at the very beginning. However, in the back-end these are two separate applications. They don’t depend on each other and they don’t even know each other. So I kept both SoC and the Law of Demeter in mind, when I built this. Doing so results in more freedom and flexibility. I could easily build another customer-dashboard – with another source of data – and it would show the customer-tickets from the very beginning, without me touching the ticket-application. Or I could replace the ticket-application by one that is a bit more professional.
I hope you enjoyed reading this. Please leave a comment if you have any questions. You’re also welcome to try it yourself. There is a 30 day trial of Intrexx, which starts in just a few moments, if you want so.