Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
A new GA AppWorks platform version 22.2 is available for Q2 2022. In this post we’ll have an update on the new features released for this version!
Let get right into it…
The main installation menu gets an update to 22.2!. Why? Well, the CentOS “storm” is here! This means CentOS deprecates from OpenText support! Check this line: Support for CentOS has been deprecated from the AppWorks Platform 22.2 release. The only strange thing is this image from the “OpenText AppWorks Platform Supported Environments” documentation:
This tells me, it’s still working; only not supported by OpenText, but I don’t want to sit and wait…we just go with the flow on the no-cost Red Hat Enterprise Linux individual developer subscription
!!Spoiler-alert!! Also OTDS gets an update…In my preparation, I saw already a required upgrade of Tomcat to version 10, and a removed / missing “opendj” service
/opt/opentext/otds/opendj/bin/start-ds!? For your understanding…I didn’t read any documentation yet, but I just saw this in my pre-VM! There is also a database requirement where OTDS stores its data from now on!
In this post we’ll review the (AppWorks Platform CE 22.2 Release Notes) delivered with the installation package. We’ll do a deeper dive on the newest functionalities delivered in this GA release. More information is also available in the release notes PDF.
From previous releases I learned about Q2-release. They are major with a lots of nice features for this upcoming year. I already did a sneak-peak on the release notes, and it’s indeed MAJOR. This post will give you a proper overview of the ‘new stuff’. Let’s jump through the list of new released features.
Normally, the deprecated features get an explanation in the end. Because of some major changes, I move them to the front of the post.
As mentioned in the intro; CentOS is out of support at OpenText. Although it should still work according to the release notes I also pack my bag and move to RHEL with the no-cost developer subscription. Works the same, but with a registered user account…It is what it is my friends.
An interesting ReST-change with a new health check URL:
http://192.168.56.107:8080/home/appworks_tips/app/mp/health/ready. It returns a JSON result like this:
This response totally meets the now-a-days standard ReST end-points with JSON response. This makes it also easy to create a small dashboard for status monitoring on these services. Wonderful job!
Finally…I can put my ‘head’ into runtime! 😁
More information is available when you open your profile after clicking your own name:
The information shown is retrieved (in my case) from the related OTDS account.
From the same user profile settings, we can now add up to five e-mail signatures (you can mark one as “default”).
To try this feature, have yourself an ‘Email’ BB applied (incl. the ‘Emails’ panel in the default ‘view’ layout) to an entity. Once in place, you can create a new mail where you see the default signature applied:
WAIT…What about the mysterious ‘Reset all’ button for the entity preferences!?!? Yes, have a view again in the screenshots!
Time to put our developer tools in place with
<F12> and make sure our database logs in monitor-mode:
sudo vi /var/lib/pgsql/data/postgresql.conf
Hit the ‘Reset’ button like a pro:
If the button is greyed-out, you need to change something in your UI. Like a column width for a result list. After logout and login again, you should be able to hit the button.
I see a DELETE-ReST call passing on this URL:
From a database perspective it will do delete statements on this table
O2OpenTextEntityIdentityComponentsPersonalization. We saw this table already passing by in the 22.1 release
Now we move to the next one…
It took me some time to find this feature in the UI, but a little back-end help brought me into design-time! Open a form; like the ‘Create’ form. When you add a relation to the form (toOne or toMany), you are required to select a corresponding list from which to select your value. Behind the list-selection is a filter icon:
For this post I created a ‘project’ entity with a ‘toMany’ relation to the Identity package entity ‘User’!
Clicking the icon lets you create a more advanced filter (incl. the expression functions!)
Great update; let’s jump to the next feature!
Feature report: This same “enhanced” filter option is not available from a layout point of view! Here we can add a result-panel with a selected browse-list; only the filter option behind this one is still the same.
I saw a beta-demo of this feature in one of the partner sessions of OpenText a year ago! It looks like a high priority feature as it’s already available in 22.2…Nice, but how does it ‘smell’ and ‘feel’!? For this we dive into the created ‘project’ entity where we open the generated List BB ‘lst_all_projects’. Extend your knowledge on the new ‘Report view’ tab:
Oelala…This is your runtime view (via a full-view on the list!):
You can open the full-view from the icon on the list-view:
NICEEEEE job! 😎
A full range of chart types is exposed:
Including the list of aggregations:
An interesting feature after clicking around for myself. Does it need some fixing on labeling? Probably! Does it work? For sure! Do we make managers happy (and we want to keep them happy)? Hell yeah! So, I say welcome reporting for AppWorks!
- The technique behind this? Well, it looks like they use Plotly when looking at the source from the developer tools in Chrome.
- Can we extend it with custom reporting? After questioning OpenText the answer is ‘Nope’!
Finally, I would say! It was a weird behavioral BB. You use it to “label” / “tag” your form component (like a field or a full section) and trigger a show/hide, enable/disable, or style apply action from an event type of rule. In previous AWP versions, we created those categories in the form itself, and they were visible in the entity overview screen. Only, we were not able to further manage them! Now we first need to create the category as a ‘Rule category’ BB on the entity…
…and select its usage in the form:
FYI: The ‘Rule’ BB actions itself are still the same.
I wasn’t aware of this missing feature, but OK. I just created a ‘hasChild’ relation from ‘project’ to ‘issue’, and the full list of 26 BBs (incl. the ‘Deadline’) is available. 🤗
This was indeed a missing feature! I always communicate an interesting workaround with the WS-AppServer container, but this can be removed from my list of knowledge. We get the ‘Webservice’ BB exposure on this configuration entity:
You create this entity from the context menu of the project itself. To save it to another location, you still need to dive into the properties of the entity to update the location within your own folder structure.
It looks like I’m not the only one advising to always apply the ‘Title’ BB to an entity! For fast prototyping this BB now applies automagically. Trust me, it will benefit the entity eventually:
This enables the ‘onShare’ and ‘onUnShare’ events on the ‘Rule’ BB:
The ‘Sharing’ BB is only available with an applied ‘Security’ BB. Sharing works with so-called ‘instance’ roles which brings a new layer of security for the “externals”.
Well, I know the work it took me to dive into xECM. It’s not worth the time to set up the whole circus for this specific feature. I love you all, but this is one step too far! 😘
What does this feature bring briefly? Well, it has a small relation with the current sharing-events on the ‘Rule’ BB. For the ‘Sharing’ BB, we require instance roles, and the feature enable AWP administrators to map instance roles to team roles in xECM. We all know by now that xECM is powered by ‘business workspaces’ secured by those team roles! On sharing a business workspace this feature makes sure the user automagically is added/removed from the corresponding team role. This makes it a seamless secured share when you apply the ‘Business workspace’ BB to your entity.
It’s great to see there is still investment in the AppWorks documentstore connector to Documentum. I played with this connector before which requires an OAuth authentication through OTDS! Great stuff to play around with, but not for this post.
What is changed? It looks like a better support delivery on the checkout/check-in functionality for content! A great extension which comes with a visual indication on the checked-out document. When the document checks out, we now have the action available to ‘Cancel checkout’ the document again. This is all seamlessly synchronized within Documentum under the same user account. Other related content actions dynamically show/hide based on the state of the document.
There is also metadata support for uploading files using the File BB. This means the ‘File’ BB itself starts to behave the same as the ‘Content’ BB. The
/app/admin section can be configured also for content uploading via the ‘File’ BB; meaning to select the default Documentum document type like
dm_document to use.
Finally, editing documents without applying rendition is enabled which downloads the content. The user has the ability to open it (without any rendition) in the local editor.
From a demo I even see a download of a local client named
The end-goal will be to create the most seamless editing ‘feeling’ for the end-users from a web-application perspective! We as ‘developers’ know this is a challenging task with all the security limitations within a browser. Do you still have nightmares about all the ‘ActiveX’ struggles we had in the past? 😭
AppEnhancer (AE) is formerly known as ApplicationXtender (AX). See the OpenText product page and get yourself informed about another Content Management System…Interesting! Especially after my experiences with “Documentum” and “OT Content Server”! 🤗
After some research I come the conclusion this product is from the EMC-era. AppWorks uses an Original Equipment Manufacturer (OEM) module which makes AE a supported ECM. Well, looks like it has its own light-weight customer-base for small businesses (5-25 users). I’m not a sales guy, so I don’t know anything about the costs/licenses!? Comment me on that one!
From my point of view there is zero experience with this product. A minor issue for now, but I definitely place it on my backlog to have a view in the future. I know this ‘AppEnhancer’ is configured from a service container of connector type ‘Document Store’. So, let’s see…
Concisely the features for this release:
- Viewing of documents using AppEnhancer viewer; Looks like it is delivered with its own viewer which we can configure in the ‘Document Store’ service container. In the past we also saw Brava!, and the new Intelligent Viewer for other ECM platforms.
- Configurable parameters for AppEnhancer viewer; In the
/app/adminsection of AWP, the administrator has the ability to pass parameters into the viewer. These can be static or derived from entity property values.
- Synchronize entity data with AppEnhancer application records; AppEnhancer is based on an ‘application’ containing ‘records’. From the AppWorks point of view it’s possible to synchronize entity data into the application records of AE.
Let’s see if we can embrace this CMS in the future…
‘Red Hat’ OpenShift? Yes, my friends! Just another cloud “Hyperscaler”. Have a read here where all the buzz-words come together: ‘Kubernetes’, ‘Containers’, ‘Hybrid clouds’ and ‘Edge deployments’. Others (like ‘Google cloud’, ‘MS Azure’ and ‘Amazon AWS’) went ahead…This is the decisive moment for ‘Red Hat’!
Some history (also for my own recap):
- We have just our own local machine (on-premise!?)
- We have servers under our desk (on-premise!?)
- We have server-racks in a local server area (on-premise)
- We have server-racks in a remote (third-party) server area (off-premise)
- We have server-racks at hyperscalers/providers (cloud)
On these servers we started to run Virtual Machine images. Why? Well, to share resources and use maximum hardware capacity. Because they were ‘Virtual’, it is easy to replace them with new ones. Also, the demand for quick delivery of systems got bigger.
On these VMs, we started to create containers (like Docker)! Small VMs within a VM. Why? Well, to share resources again, but this time for smaller tasks. So, where VM’s run monolithic applications, we start to see a shift to microservice applications (loosely coupled for scalability).
To manage all these ‘small’ containers, we required some orchestration (like in music) where containers all work together. This is where Docker compose (with Docker Swarm for networking/clustering) comes in place with a light-weight solution. When things get bigger, others come in the picture! Kubernetes came in sight with its Helm-charts for more power, self-healing, and auto-scaling ‘pods’. To put the cherry on the case, Docker-registries where introduced (like
https://hub.docker.com/). Docker containers lean on templates hosted at these central registries. Helm-charts further automate the consuming of it! We also start to see cloud providers have their own registry possibilities (like Red Hat OpenShift ImageStream).
So now you see where it all started and where we currently are. We see abstraction, over abstraction (like in programming) to make tasks as easy as possible for the end-users…Nice to see how this evolved in the last couple of years! Where will it end?
Download the AWP containerized installation package if you want to give Helm-charts a shot. This is only the platform (with CARS/OpenLDAP)! So, no OTDS and other related services like viewing (Brava!, Intelligent Viewer) of CMS (Documentum, OTCS). Will it benefit? For the long run it will; especially when you have a full Dev-Tst-Edu-Acp-Prd architecture to manage with fail-over and high-availability features. Another benefit is the possibility to create pre-installed solution containers. This makes ‘packaging’ with CAP files unnecessary as the container can be built from sources in SVN. Is this an easy task to do? For sure not, but it’s just a possibility to consider in your team.
Have a look in the ‘OpenText AppWorks Platform 22.2 Cloud Deployment Guide’ guide for chapter 12 “Deploying Application images on Red Hat OpenShift”. In quick steps (I never did it for real):
- Install Helm
- Create a ‘Red Hat’ account
- Install OpenShift CLI
- Install Red Hat OpenShift Service on AWS (ROSA) CLI
- Install AWS CLI
- Download the Helm charts from OpenText support
- Config storage providers
- Config Ingress for OpenShift cluster (enables external access to OpenShift Container Platform cluster services)
- Have credentials available (for the database)
You see already a lot of modern technologies passing by in this section of the post. This is exactly why containerization is a challenging task to do (where I leave the whole Continuous-Delivery / Continuous-Integration discussion out of scope!). 🤓
Let’s continue our grind…next one…
It’s an enhancement on the ‘Task Outcome’ BB. We saw a glimpse of this building block first time in AWP 21.4 and will work together with the next feature on dynamic workflows!
We can find this one in the related ‘LifecycleTask’ entity when you apply the ‘Dynamic workflow’ BB (since this release) to an entity. Yes, it’s the same ‘LifecycleTask’ entity when you apply a ‘Lifecycle’ BB! You create new types of tasks reusable in a flow. It’s also possible to configure a mapping from “task type” to an ‘Enumerated Text’ property. I don’t understand this mapping feature yet, but let’s see if the next section can show the value of it.
To play around, I have my ‘project’ entity available with an applied ‘Dynamic workflow’ BB. On the related ‘LifecycleTask’ entity, I create a new property called
task_outcome of type ‘Enumerated Text’ with some values:
I configure the already available ‘Task Outcome’ BB like this for now (as preparation for the next section)
That’s all…No forms, no layouts on the entity (yet!?)…Let’s dive into the next section!
Beta release? Should be something big…right? We already saw this one communicated in the field. This feature brings the power of lifecycles and BPMs into runtime! This way your “business consultant” can create its own processes to facilitate the end-users. It’s even possible to create it template wise…Let’s see! Hit it like a pro:
Nice…A fully building block enriched entity called ‘DynamicWorkflows’:
What can we do here? Well, this is all about a running instance of the (dynamic) workflow! So, add an ‘onCreate’ rule event, show a form/layout when opening the flow instance? Add content? Expose CRUD webservices to get a grip on the instances!? I don’t see it yet, but the possibilities are great. I keep it all default for now and just publish my project to see what happens in runtime?
Create yourself an entity instance, open it (with the default layout), and hit the gazzz:
This “smells” like ‘Activity flow’ BB 2.0 directly in runtime…agree?
Ok, let’s start simple…change the ‘Category’ from dynamic to static, update the ‘Due type’ to ‘Duration’ and apply a value. Now it’s time to hit that blue ‘Start’ button!
Now what? Should there be something magic booting up?
The PIM? NOTHING…?
The CIM? NOTHING…?
One step back…Make the category ‘Dynamic’ again, update the task information on the first step and ‘Start’ again! This time something executes as the dialog closes…great!
The PIM? NOTHING, but expected as we’re in entity modelling land!
New workflowmatches the name in runtime
Stepalso matches the name in runtime
Time to update our ‘project’ default view layout and apply a new type of panel called ‘Workflow Instances’. After a publication in runtime we get an interesting panel:
I’m already filled with questions at this moment, but my first question would be: What is the difference between a ‘Step’, and a ‘Task’? We can create both of them behind the ‘Plus’-sign button. My first gut-feeling:
- Step: Relates to a ‘State’ like we define in a ‘Lifecycle’ BB on an entity!
- Task: Relates to an ‘Activity’ like we define in a ‘Lifecycle’ state on that same entity!
For now, I just create a new ‘Draft’ step with a task ‘General task’ named
This is a draft task. This will be the “outcome” after the completion of the initial task:
FYI: These tasks are also available from your ‘My Inbox’ node from the homepage perspective. I assume, or quite sure this feature integrates fully with the ‘Identity package’ of the platform.
Nice…How about a ‘Progress Bar’ on the ‘project’ default layout of type ‘Dynamic Workflow’? 🤗
Looks like my week-end will start greatly!
What else? Well, my head is full of question…let’s jump through them:
How about a related-task-entity ‘Default’ form as it’s empty when opened?
Open the related ‘LifecycleTask’ entity from the ‘project’ entity and add a new form with name ‘Default’. I place two properties; The ‘Task outcome’ property of type ‘Enumerated Text’, and the ‘TaskType’ property of the ‘Task outcome’ BB:
From the created mapping perspective before, I expect the value sets automatically on the property based on the task type mapping! Are you still with me? So, when I create a new task (based on my task type), the value of my Enum is set! Let’s see in my next question…
How about the ‘task types’ on the task outcome BB we’ve created in the previous step?
Time to create a new task again (within a step) in runtime based on my own created task type:
Open the task and check the ‘Default’ form view for the task (with those two properties)
Looks like the applied mapping works fine for further usage (although I still don’t see the use-case yet!?)
What about workflow templates?
Create a new dynamic workflow in runtime on the entity instance. Make it one step, with two tasks, and hit the ‘Save as template’ button.
You get a modal popup to set a new name and provide it with a status
In draft (in my case). Once saved, we move back to the ‘Home page’ to have a look in the ‘Workflow templates’:
Open the template and make it ‘Active’:
Now what? Well, how about creating a new workflow again from the entity perspective (like before!). Yes, my friends…Now we are able to select our ‘Active’ template!
What is the trick behind the ‘static’ flow?
Time for a new workflow again…We start ‘Dynamic’, add some steps/tasks to it, and switch to ‘Static’
After ‘Start’ (this time it works better), we see indeed a ‘Static’ flow instance passing by in the UI. You don’t have the option to add new steps/tasks:
How can we ‘open’ a workflow instance?
Well, for this we require a ‘oneToMany’ relation on a form! For this we open the ‘Create’ form of the ‘project’ entity where we add the ‘DynamicWorkflow’ relation. Add some properties like you would “normally” do and publish it. From a runtime perspective we see indeed a list of flow instances which we can also open:
Now I see also a “stranger thing”; The right ‘Workflow instances’ panel is not an ‘instances view’, but more a ‘one-instance view’ (my second flow is not available from that panel!?…Beta?)
Time to ‘open’ a workflow instance, but not before we add a ‘Default’ form to the related ‘DynamicWorkflow’ entity (otherwise we end up with a white screen)
I hit the ‘Terminate’ button, and I also delete some workflow instances…Just to get a better feeling for the next questions…
What about monitoring and maintenance?
Great question? For workflows, we normally depend on the PIM artifact, but that’s not the case here. We have a small piece available in the CIM artifact, but this feature runs on entity level and for this we have the ‘History’ and ‘Tracking’ BB available. Is it sufficient for administrators (especially when we start using event type of Rules that trigger a BPM!?)? Time will tell!?
What about security?
Well, it’s entity modelling, so check the ‘Security’ BB!…On three levels:
1. The entity itself
2. The related ‘DynamicWorkflow’ entity
3. The related ‘LifecycleTask’ entity (with the ‘Task outcome’ BB)
What about the due-date on a task?
Only one way to try it out! Create a new workflow with a one-minute duration! Get a coffee and check the runtime for any flag.
FYI: There is no flag raised out of the box!
Hmmm…I expected to create a ‘Duration’ BB on the related ‘LifecycleTask’ entity to initialize an escalation, but this BB is not available!? This asks for a workaround to create but is out of the scope for this post! Comment me if you see this differently. We did something similar in this post at BPM level; The same should be possible on entity-level for a task…I placed it on my backlog!
What about audit?
Again…Entity data which can be enabled in the ‘Audit Configuration’ artifact (in the ‘System’ space)!
The ReST point of view!?
/app/admin time, where we have the possibility to dive into a whole new layer of entity ReST services:
Looks like this layer gets increased “balls” with an extended list of operations:
I have it on my backlog
Consume Swagger API with JS frameworkfor a future post. This post already does the ReST authentication part via Postman.
That’s it…Playground 22.2 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 2022 Q2 release. Happy low code with this brand-new release, and I see you in the next post!