The R&D prototype of the Netgrif platform dates back to 2008. Usually, when people ask me, what is the key difference between us and our competitors, my answer is our Low-code language Petriflow and the wide range of possibilities it can provide in combination with the Netgrif platform. As prof. Gabriel Juhás says, that with Netgrif and Petriflow you can go as low as possible and have your applications as rich as needed. The language is process-based and by simple no-code drag’n’drop, you can create data with forms, roles, queries and workflows!
Where is the low-code part? It is present when you create actions – this is the main focus of this article so from now on, read carefully.😀Actions are pieces of code (small or big, they can be even pro-code – about that a bit later in this text) that allow you to react to events in everything our Petriflow process-based applications include. Why are actions low-code? By parametrizing our pre-prepared functions – ActionsAPI – you are creating actual code that was not typed but parametrized / low-coded. In the future possibly be generated by Chatting.
Here is a simple demo of reacting to events using only our ActionAPI:
In the example, you can see the creation of a process-based application in our tool Netgrif Application Builder (NAB). After I finished creation in just a minute, the source code in the language Petrfilow was downloaded and later uploaded to another tool called eTask where our Netgrif Application Engine (NAE) is running. The eTask with the help of NAE can in run time compile/interpret source code from Petriflow on the server, without the need for deployment. The whole deployment of the Petriflow source code is done by uploading the file. And since the moment the Petriflow application is uploaded and compiled into the three-tier architecture of the eTask web application, users can (if roles allow them to do so) create new process instances that we also call cases of process-based application.
In our process-based application example, one form with name and surname is created. The user can then create a new case and in the first form/task fill in his/her name a surname. After finishing the first task, the second task is executable, where users can see the values of name and surname joined with some extra text in the third text field called status. How were name and surname joined? By simple ActionsAPI called Change value.
But what in case you want more functionality than our ActionsAPI provides? We believe that since you are not working on big process-based applications, it is not necessary. But in case you want something out of our scope you can easily extend the scope of ActionsAPI in your local version of eTask.
Here is how you can extend your ActionsAPI:
Our eTask is a three-tier web application with Java Spring Boot in the backend. That means a simple thing, developers who are not full-stack web developers, but people who can implement simple functions are able to extend their/our ActionsAPI. How? By simply adding a few lines of code into the file CustomActionsDelegate in their own eTask application that can be downloaded for free on our GitHub – Netgrif free Community Edition on GitHub! Or request this functionality from us, and we will implement it into the NAE.
In the example above, a simple functionality creates an image file from the provided text. The generated picture is a QR code (in our case a link to Netgrif’s LinkedIn page). On event, after the value to text field is saved a picture is generated. The first/task form contains a text field and a file field where the user can edit the values of fields. In the second form/task, the user can only see the file field, and open or download the picture.
The summary of my first-ever Monthly update is the thing I already mentioned. With Netgrif and Petriflow you can go as low as possible and have your applications as rich as needed. The wide range of functionality that our tools, functions, no-code and low-code provide is more than enough for so many cases of everyday life in terms of software development. In the not so far future we will present plugins. What are plugins? In the same way, you just simply upload the Petriflow source code into the running eTask/NAE application but for Actions in the form of a package.
Process-based applications like those you’ve seen in this arcticle can be found here: https://academy.netgrif.com/
Actual case studies where things mentioned in this arcticle are on this link: https://netgrif.com/case-studies/
A specific use case of application developed for the end customer where basically everything instead of integrations were realized by only ActionsAPI can be found here: https://netgrif.com/case-studies/online-contracting-system-for-energy-supplier/