Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
The new GA AppWorks platform version 21.1 (also known as version 21 EP1) is available. And as you (probably) already know this is made available for Q1 2021 and in this post we’ll have an update on the new features released in this version!
Let get right into it…
The main installation menu got an update for you to consume. It provides a 10 steps procedure to install a AppWorks environment from scratch. This post will do a review on the release notes (OpenText AppWorks Platform 21.1 Release Notes) delivered with the installation package. We will do a deeper dive on the newest functionalities delivered in this GA release. More information is also available in that release notes PDF.
With a new version of the platform we also get a lot of new functionality. This will give you a proper overview of the ‘new stuff’.
Let’s just jump through the list of new features in the release notes and see what’s up in this release.
Since release 20.3 the auto logout functionality is available with a setting in the ‘wcp.properties’ like this example:
After a restart of our TomEE we raised the default 15-minute timeout till 90 minutes.
Thanks to OpenText support we saw this parameter got an update to this setting in that same file (with still a restart of TomEE):
With this release we get a model popup in runtime with a choice to make for the end-user when the session is inactive for that time period:
When you wait the full 60 sec.? Well, you will be brought back to the login screen…duh!
This also applies for the AppWorks Administration ‘/app/admin’!
With this release we get smart caching for static files that will fully use the browser cache, but what does this mean? Well, the AppWorks client depends on third party libraries like for example Aurelia.io and KnockoutJS. Those third-party libraries got an upgrade to a later version which makes it possible to also use the latest features on those libraries. When you do a search on Aurelia / KnockoutJS and caching on Google you will see there is much to discover in this area…A great job that we reap the benefits from it on our platform.
A ‘section’ can split a form vertically in several parts. Each part will have a certain high on the form. When you place a grid component on a smaller section you would like to have more control on the responsiveness off that grid vertically. This is facilitated with an ‘Auto resize’ option, and the numbers of items in the grid that are required before we get a vertical scroll bar:
Steps to see this option:
- Create a vertical section on a form BB
- Drag & drop a ‘oneToMany’ relationship on to the form
- Change the default ‘Repeating group’ type to a ‘Grid’ type
In runtime this will be the difference:
The top grid is ‘auto size’ enabled with row size 3; The bottom grid is unchanged.
A ‘simple’ user does not have any access to the ‘/app/admin’ section of the platform. You need to be a member of the ‘Administrator’ role.
Sounds like a ‘security’ option we apparently would like to have enabled by default…Well, fine by me!? But it raises questions:
What does it do?
It all has to do with Cross-Site Request Forgery and Cross-Site Scripting; also called XSS. In simple words: It’s a security attack on already authenticated users and let them submit unattended requests to the already authenticated web application. So, another person will reuse the authentication information of an already logged in user to submit request like ‘delete a record’, ‘purchase a product’ or ‘change a password’. How? Well, during the login procedure a cookie is create with values of the SAML artifact (which is user information), and the ‘HttpOnly’ flag makes sure the cookie has protection from XSS! But why create such a cookie? Well, because you don’t want to login again and again for each request to the server.
Where can we find it?
It’s a setting in the ‘wcp.properties’ file that looks like this:
I see the 21.1 admin-manual is telling me it still defaults into ‘false’!?
After a quick login test in Chrome with the developer console open I can clearly see it’s enabled by default (as the setting is not applied in my ‘wcp.properties’ file!):
Other resources on this security topic:
An image can describe a thousand word…
I don’t use the ‘Activity flow’ that much, but it kept me clicking through the other BBs, and my first thought is: Why is it not possible to update the name of a ‘Property BB’ in that same way? Well, maybe I do know the answer with all the relations it has to other BBs, but it would be a great feature for a next release!?
It might happen that a crafted ‘Business Process Model’ like this simple example…
…gets an ‘Aborted’ status on an activity when it is executed. In my case I didn’t connect a service container to the ‘Readcase’ webservice, so it does not know where to send the request to. From the ‘Process Instance Manager’ artifact we can easily get an overview of what is happening in the current running process instances. Normally we would mark the aborted process instance, and we can hit that ‘green’ play button to start the activity again for a second try (after we’ve resolved the issue that caused the abortion!). It will give a modal popup on what to do next:
Now there is a new feature in town which makes it possible to restart the process from start:
It will provide us with a modal popup that looks like this:
Almost the same dialog, but slightly different as you can see…
When you have a look at the activity overview of this current process we also see a nice reference on the actions where the ‘Administrator’ replaced the activity instances with a new status (In my case it’s going wrong again, but that’s just the demo):
I read already about this feature and saw it also passing by during the creation of my service containers, but never stood still on this feature…till now!
It’s (I guess?) this feature that is available in some service containers (like BPM, Rule Engine, Schedulers, and CoBOC ) that we can create:
With this selection we get a modal popup which we can point to an external database table out of scope of the default AppWorks platform…
Interesting stuff…I also placed this one on my backlog to play along with!
More about this feature can also be found in the ‘Administration manual’ under section ‘Changing the database configuration for service containers’ as well in the section ‘Managing database configurations’.
For this release it looks like ‘other’ components / ‘service container connectors’ are also “external database” ready, although you can’t configure it (yet!) from the UI like the above example. We should contact OpenText support on this one if you really would like to have such a feature on that particular component. I don’t know how often this will really happen as you probably want to save information to another location when:
- …the data gets too large
- …you would like to maintain it separately from the rest (like we can do for content, and for log files)
- …security is higher on the list (this all has to do with access, responsibilities, protection, and data preservation)
Also, in the packaging of a solution we need to keep in mind this external data and during deployment it is possible to create the required tables in a database that can be consumed by the configured service containers.
After a quick search on my VM:
sudo find /opt -type d -name 'createscripts'. I get a result like this:
All these directories have database-type specific scripts to rebuild a database for that specific component…Nice information to know and it might come in handy for the future…Who knows!? 🦁
The future off AppWorks will bring us a new type of viewing support under the name of ‘Intelligent viewing’. It is a replacement for Brava! that will be introduced at the moment in combination with ‘OpenText Content Server’. You will get the option when you create a new ‘Document Store Connector’ to store content to the external ‘OpenText Content Server’ platform. I’m also a ‘Documentum’ enthusiast, but this option is not (yet!?) available for this type of storage.
I personally don’t have that much experience with the ‘OpenText Content Server’ platform (yet!), but I do know that content will be served through the ‘Business workspace’ BB on an entity level.
With this feature it’s also worth to spend some time on this platform too…I place it on my backlog…How hard can it be!? 😜
In the supported systems section of the PDF we see a discontinued support for RHEL6.x and CentOS6.x. A valid choice, but there is more to talk about! Maybe you read it on the interwebs, but there is something going on for these distributions of Linux. You can read here where ‘Red Hat’ deprecates CentOS Linux in favor of a streaming edition! Normally I do my installations on CentOS (21.1 is still on this distribution) as it is free in use for the intentions I use the platform with. That is to help you all with your AppWorks goals and to grow in my own experiences. So, CentOS is a basic component for the blog posts on this site, but after some research it made me clear we might do a switch to RHEL for our installation. We can read here ‘Red Hat’ is making a ‘No-cost RHEL for small production workloads’ distribution available for developers…How nice! It will be (as far as I understand it) a fully functional RHEL distro downloadable from here. The only thing we as developers have to do is the creation of a free ‘Red Hat’ account and off you go. You probably will need to have the account available once you start installing repository packages onto a clean and empty VM, but we’ll see. It’s worth a try, and I will definitely update you on this change.
I also asked the OpenText AppWorks team how they will react on this change, but there is not (yet!) a final decision made on this topic.
That’s it…Playground 21.1 is open and ready to be used. I give it a ‘DONE’ on this update post with a nice overview of the new features for this GA 2021 EP1 release. Happy low code with this brand-new release, and I see you in the next post!