Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

A new GA AppWorks platform version 21.3 (also known as version 21 EP3) is available since Q3 2021 (that was last July!). In this post we’ll have an update on the new features released for this version!

Let get right into it…

This time the main installation menu still has the 21.2 installation applied!. Why? Because I could plot that installation one-to-one on the 21.3 installation (incl. all the software versions for TomEE, Java, and PostgreSQL). So, the 10 steps procedure to install an AppWorks environment from scratch is still a great post to follow for this new release. In this post will do a review on the (AppWorks Platform CE 21.3 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.

🆕 Update on the available changes in 21.3 🆕

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.

Layout form panels loading behavior (in a tabbed panel)

Let’s just built it and see the option in real life…

I create a ‘sample’ entity with just a ‘name’ property and all the default BBs for quick prototyping…Now have a look at the ‘DefaultLayout’ and let’s drag & drop a second ‘Form’ panel on top of the current ‘Form’ panel:

Interesting…So when we have for example a second ‘Form’ with a required field on it, and we remove that selected option, it will not complain directly on layout opening with a ‘Required field’ notification in runtime. It will only complain when you enter that tab!?

I quickly tried out this scenario and that’s exactly what it does…nice feature! Behold the power of the ‘lazy loaded tab’! 😉

OAuth support between AppWorks and AppWorks Gateway

Great, but I’m not trying it out now (if you don’t mind). What I can tell you is there is a post available where you see me struggling with the mobile BB on an entity and indeed the ‘AppWorks Gateway’ to serve it to a mobile phone on BlueStacks. I saw it once working at OpenText, but never on my own configuration…Also, a topic on my backlog (especially now it’s again in the picture with this OAuth feature!)

Use configuration properties in homepage actions

When you create a new ‘Homepage’ type of document (saved in your ‘homepages’ folder of the project!) you have the ability to add new action (like a URL) on top of that homepage (next to the ‘User’ icon in the top right corner in runtime)

When you open the expression editor, you have to option to select properties of the global so-called ‘Application Configuration’ entity!

I hear you say…”Application Configuration”? Well, right-click you project and check the corresponding action! It creates a new kind of entity with global configuration settings. How to apply a value once published? Have a look in the ‘/app/admin’ section of the platform:

This ‘special’ entity also has all the BBs applied, so you can even trigger rules for interesting business logic!

Export result list

Firstly, let’s extend the ‘sample’ entity from the first feature with some more properties…Why didn’t I do that in the first place!? Now we also need to update all the other BBs! Damn me! 🤔

OK…We have some data…Let’s do the Excel export from within runtime:

Works as expected:

Now, we remove the ‘Description’ from the columns list (with the far-right hamburger menu!)

In the re-export I indeed see the ‘Description’ being gone from the export (as from now on only visible columns are exported). Maybe in the next release we get an optional modal pane where we can select what columns to export…Who knows!? 😎

A layout requires at minimal 1 panel for correct publication

Well, I wasn’t aware of this limitation (what is the point to publish an empty layout!?), but let’s try…Create a new layout and publish it directly!

That’s also the same for a ‘Home Page Layout’ of type ‘Reusable’…Trust me! And even the homepage layout itself (tabbed / regular).

Auditing enhancement on entity runtime instances

We saw an ‘Audit’ enhancement before in release 21.2. I guess ‘Auditing’ is high on the list because of the FedRAMP compliancy the AppWorks platform wants to meet. Indeed, a good thing as it brings ‘Continuous Monitoring’ to a next level, but what is changed?

Let’s dive into the ‘/system’ space and have a look at the ‘Audit Configuration’ artifact…I directly see 2 new options:

A quick dive in the ‘Administration guide’ with a search on ‘Audit’ brings me to a table with this information:

The release notes tell me this ‘access’ audit recording also works via exposed webservices on an entity.

From the ‘Audit Viewer’ artifact we will now be able to search for runtime audit events pertaining to ‘Rules’, ‘Lifecycle’, ‘Activity flow’, ‘Assignee’, ‘Task list’, ‘Sharing and security’ (incl. the building blocks configured for any EIS related entities)

XML Store access closed by default

When you have the ‘Developer’ role applied to your account, you will also see the ‘XMLStore Explorer’ artifact. It’s a location to store XML data. The platform itself stores information into it, but with a new document of type ‘XML Store Definition’ in your project we already learned to save our own XML files into this storage location. Like this:

We even learned to read that same data via a SOAP service call on the GetXMLObject service operation:

1
2
3
4
5
6
7

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP:Body>
    <GetXMLObject xmlns="http://schemas.cordys.com/1.0/xmlstore">
      <key version="">/nl-bos/test.xml</key>
    </GetXMLObject>
  </SOAP:Body>
</SOAP:Envelope>

How about a ‘regular’ user account like my ‘awtest’ account via the ‘/services’ area of the platform!?

Well, looks like a ‘closed by default’ to me!

Back to our ‘awdev’ account to set the security on the folder in the XMLStore itself:

For now, I just set it like this (don’t forget to apply and save it!):

A retest with the ‘awtest’ account gives me a green light!

But we can do better!! What I also read in the release notes (even recommended by OT) is the right-click option ‘Define Runtime Security’ on the folder in the project? Well, almost correct…Not the folder, but the ‘XML Store Definition’!

After applying the ‘Internal’ xml_store role (saved nicely in the ‘roles’ folder of the project) to my test account it’s still working! And duh! I did remove the ‘security’ from within the XMLStore itself…You smart-ass! 🤓

Upgraded Log4j to Log4j2

Interesting as I can remember explaining to you all we have the ability to update a file called ‘Log4jConfiguration.xml’ in this location on the server: cat /opt/opentext/AppWorksPlatform/defaultInst/config/Log4JConfiguration.xml!

In this file we could do things like this to output debug statements for our custom code namespace:

1
2
3

<category name="nl.bos"> <!--Your custom code-->
	<priority value="debug"/>
</category>

From now on this file is called: Log4j2Configuration.xml (with an extra ‘2’)!!

Let’s have a look: sudo vi /opt/opentext/AppWorksPlatform/defaultInst/config/Log4j2Configuration.xml

The file looks initially much smaller in content size….Maybe that’s me!?

It starts with an interesting property:

1
2
3

<Properties>
    <Property name="logsFolderLocation"><!-- Provide custom logs folder location --></Property>
</Properties>

In every project I discuss this kind of setting because it has one big disadvantage and one advantage!

• Advantage: You can save it on a central location with all the other logging (maybe a separate share to gain external access or maybe a location where it’s in the backup cycle)
• Disadvantage: Every new AppWorks person working with the system needs instruction where to find any logging at all (because it’s removed from the default location)

The next section is an ‘Appenders’ element where we describe what/how/when log files are creates…I just leave it as is.

Next we have the ‘Loggers’ element…This is the location where ‘probably’ our namespace can be logged like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<Loggers>
    <Logger name="com.cordys.cap.applicationconnector.CAPMethod$CapLogger" level="info" additivity="false">
        <AppenderRef ref="ApplicationNameBasedAppender"/>
    </Logger>
    <Logger name="com.eibus.management.AlertSystem" level="info">
        <AppenderRef ref="OSBasedEventAppender"/>
    </Logger>
    <Logger name="com.eibus.management.ManagedComponent" level="info">
    </Logger>
	
    <!--Your custom code-->
    <Logger name="nl.bos" level="debug"> 
    </Logger>
    
    <Root level="error">
        <AppenderRef ref="file"/>
        <AppenderRef ref="CordysZeroConfJDBCAppender"/>
    </Root>
</Loggers>

FYI: I didn’t try it out as my brand-new image doesn’t have any custom stuff (yet)! 😕

Setup xECM as a repository for email attachments

Hmmmm…”E-mail configuration” on the platform…Not my favorite hobby, but let’s have a quick dive to see what we can find for this new feature!

Back to the ‘sample’ entity (with the extended properties crafted earlier this post) and add the ‘Email’ BB. Directly we see the feature which is described for this release:

‘Business workspace’?? Yes…That’s the xECM part of the OpenText Content Server platform! You can only select the option when you also have the ‘Business workspace’ BB in place; the business workspace will only work when you have a documentstore service container up and running of type ‘OpenText content Server’; this service container will only run when you have actually ‘Content Server’ up and running and let this last part not be the case on my VM! Too bad, but I believe OpenText on their blue eyes this feature works fine! 👼

Lifecycle models and activity flow migration to build engine 2.0

What? “The new 2.0 build engine of CWS”?? And it improves build and publish performance, thus smooth deployments!?!? These are the statements we would like to hear as a developer, but what’s exactly improved?

The ‘Collaborative Workspace’ service container in ‘/system’ still looks the same with its configuration!?

Ok…At code level in the JARS? I always make a copy of this structure to my local machine for development dependencies:

Let’s have a compare with WinMerge on this version compared with the previous 21.2 version…We leave the ‘certificates’ and ‘crosscontext’ folder out of scope and get a compare like this by starting on the ‘config’ folder:

The Log4j2 was already described, and the other files are not that different after all; Just some hostname and password encryption changes which are logic.

The ‘lib’ directory for the shared object files (for windows we normally have .dll files)

Not that interesting…Looks like usual update stuff to me.

Next is the ‘ext’ folder:

hmmm…An introduction of JNA!?!? next to the expected log4j update!

I know Java Native Interface where we are able to make a call from Java to for example a C++ program! Aha!…let these C++ programs exactly be our updated shared object files in the ‘lib’ directory…So, that’s why those are updated! What about JNA!?…Let’s google! with an interesting first hit on “JNA: A Cleaner Alternative to JNI?”, and I also find pros and cons on performance for JNA vs. JNI. It’s a bit out of my scope, but I guess the OT development team found out that JNA is faster for accessing those shared object files on our platform.

Did we hit the heart of the performance engine 2.0 or is there more?

The ‘components’ folder! Well, there are A LOT of changes detected, but let’s focus on the ‘cws’ folder…Again a pretty big folder! pfffff…Let’s continue our lives as it takes too much of my valuable time! Let’s just ask OpenText about the new ‘CWS 2.0 engine’? to be continued…

Documentum integration enhancements

I see three enhancements passing by in the release notes…

Basic authentication support

…Really? Don’t we live in the OAuth timeframe with JWT formatted tokens? Ok, there are probably customers that need this requirement, but should it not be better to upgrade the Documentum platform? Looks like it’s indeed for the older versioned platform, but how old are we talking about in this case!? To give you a glimpse:

Edit documents using native applications

A great feature as normally when we “edit”, the file gets a checkout and will be downloaded…That’s it. To really edit it with your native application you are required to go to your download location and open the file from here. This feature solves this problem, but the disadvantage is the required installation of the ‘Documentum client manager’ on each client! which keeps track of the edited document.

With this feature we have a more seamless AppWorks ‘edit’ experience for documents stored in Documentum.

Some background information on the ‘Documentum Client Manager’:

It’s a so-called Content Transfer Functions (CTF) plugin for the webbrowser which can be installed.

These 2 OT knowledge articles provide more information:

• Documentum Client Manager (CTF) plugin
• Manually install the Documentum Client Manager extension in Chrome

From my Documentum background I’m also familiar with the so-called Unified Content Facilities (UCF) client from the web applications like ‘da’, ‘webtop’, and ‘D2’. Like for example this WDK location installer: \da\wdk\contentXfer\Emc.Documentum.Ucf.Client.Impl.application

The difference between UCF and CTF? CTF is just a new implementation of the ‘old’ UCF client. See also more information on this blogpost.

Zip and download one or more documents

Normally you just ‘mark’ one document and do your actions like ‘Check-out’, ‘Edit’, or ‘Checkin’. When you mark multiple documents, you also have the ability to download the marked documents as .zip file. My current VM doesn’t have a Documentum connection available at the moment, so I don’t have a nice screen dump for you! I guess you can imagine how it will look like (we trust OT on their blue eyes again!)

AppWorks Platform container deployment enhancements

These enhancements can be done in the MicroProfile Configuration (MPC) properties which are delivers with the Cloud Edition of the platform installation. These enhancements have to do with:

• SSL Offloading / termination behind a load-balancer
• CORS support by configuring the origins, methods, and headers.

I never faced these problems, but I’m most of the time playing with single “Monolith” VM’s. I’ve posted about my Docker installation, but this was based on ‘Docker compose’ where the new Cloud Edition is built on top of the abstracted Kubernetes with HELM charts. It’s on my backlog to give this installation a try.

Discontinued features

A small list, but interesting to know (and I also experienced it already!)

RSSE plug-in for iHub integration

This is a recognizable integration. Especially that RSSE plug-in…I can still remember the struggle I had configuring the thing in this iHub post. On the other hand, some time ago I reinstalled iHub again with indeed my own post and used OTDS for the authentication. The setup via OTDS was far easier to accomplish and even I made it come alive on my own machine to play a bit around with reports and dashboards. iHub…A great product with great features to explore.

Deployment of AppWorks Platform in Kubernetes

Kubernetes…Kubernetes…I know! It’s on my backlog, but my experiences so far our not yet mind-blowing!? I don’t know why, but maybe it’s the lack of knowledge on all the new stuff around a Kubernetes installation. That it’s the future; I truly believe. That HELM charts (over Docker compose) will rule the cloud deployment strategy; I also fully agree, but still it’s something that keeps me from diving into it (although I tried it with Chocolatey, Minikube and Kubectl). I just never made it that far to have a fully up and running Kubernetes cluster with all the components required to do my thing! You always end up with a minimal environment and when you want to add component (like iHub, Brava!, Documentum or AppWorks Gateway) the struggle starts to make all the communication work properly. What I say…Maybe that just my lack of knowledge! What I also see that it requires a lot more resources than the regular VM’s I create for my blogposts. So, it’s nice to have all the abstraction layers for an installation, but it comes with consequences. On the other hand…I just use one VM, and I agree it’s a totally different story when you have a full-blown server architecture to maintain which requires scalability and failover. Again…It’s on my backlog! About that discontinued feature: The ‘Containerization’ package normally contains 2 ways to install the platform; The example scripts way is discontinued; The HELM charts is the way to go!

That’s it…Playground 21.3 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 Q3 release. Happy low code with this brand-new release, and I see you in the next post!

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?