Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
A new GA AWP version 22.3 is available for Q3 2022. We’ll have ourselves an update on the new features for this version!
Let get right into it…
The main installation menu also got an update to 22.3 last week!. Why? Well, because we can and because I was in the “update” mood last week! 😁
In this post we’ll review the (AppWorks Platform CE 22.3 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.
🆕 Update on the available changes in 22.3 🆕
The ‘new stuff’…There we go…!!SPOILER ALERT!! It’s a bigger release than imagined!
‘Dynamic workflow’ BB (Beta version)
We covered this BB already in this 22.2 update post; It’s still in beta, but with new features…Nice!
Before we can start using the feature, we require some preparation steps. The first step is enabling the feature
vi /opt/opentext/AppWorksPlatform/defaultInst/config/wcp.properties. Add this line in the end:
feature.toggle.dynamicworkflow.enabled=true. The second step is creating an entity which has the ‘Dynamic workflow’ BB applied to it with on its layout all the panels for a smooth dynamic workflow experience.
Insiders trick on those feature toggles! Have a look (with JD-GUI) in the jar named
/opt/opentext/AppWorksPlatform/defaultInst/components/basicutil/basicutil.jar. There is a class named
com.eibus.util.FeatureToggleswhere you see it reads the
featuretoggles.propertiesfile. You can overrule the toggles in your
wcp.propertiesfile with the
feature.toggle.prefix. So, when you find
featuretoggles.properties, you can overrule it with
Simple…Create a new dynamic flow and let the task land at the current user for now. When you open/mark the task you have the option to start an ‘Inquiry’ (multiple times; if required!):
The current task gets a ‘hold’ state which tells me this is the ‘Dynamic workflow’ implementation of a lifecycle ‘Intermediate’ task! Just a quick in-between task for clarification on a specific subject.
Acknowledge task action
This is available when creating a new workflow with the ‘Task actions behavior’ option on a task set to ‘Auto complete’. This will directly complete the task from a runtime perspective, but the user can still ‘Acknowledge’ that the task is “seen”:
Actions added to the Dynamic workflow building block
For this change we move our ass back into design-time where we open the related entity ‘DynamicWorkflows’. When applying the ‘Security’ BB, you now have the ability to restrict actions from the security perspective:
When adding the ‘Action bar’ BB on this same related entity you also have the ability to only show the correct actions from an end-user perspective:
TypedRestAPIs for new task actions
Both the ‘Acknowledge’ and ‘Inquiry’ features are available from the OpenAPI ReST perspective of the platform via
/app/admin in the configuration icon of the solution:
This is the ReST URL for my solution:
I had a comment in this post: 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?)
Looks like they saw the same issue and is now solved with a dropdown switcher:
Yes, the progress bar panel switches seamless with it; although my screenshot is not showing the fanciest flow! 😊
Reject action enhancements
This requires an ‘Approval’ type of task in a workflow; When you create it and retrieve such task, you get an optional assignment modal popup like this:
TypedRestAPI for task types
For this one, we need to go back in design-time where we open the related ‘LifecycleTask’ entity which is available after applying the ‘Dynamic Workflow’ BB. Here you’ll find the ‘Task outcome’ BB where you can create your own task types. When adding a ‘Security’ BB on the ‘LifecycleTask’ entity, we can now apply permissions on the task outcomes:
Low-code EIS Connector (Beta version)
The good old EIS Connector…Remember? Why make it difficult when you can generate boilerplate code from a ReST end-point!? Ohw mama…Now we’re getting somewhere with our beloved platform! 😍
First we need to enable it:
vi /opt/opentext/AppWorksPlatform/defaultInst/config/wcp.properties. Add this line in the end:
feature.toggle.enable.generic.eis.connector=true. I just reboot the whole VM
sudo reboot and grab a coffee! ☕
Get your developer account ready (
awdev in my case) and jump into your favorite workspace. Create a new document of type ‘EIS Connector’ and see an interesting feature passing by:
NICEEE…OpenAPI!? My developer heart starts to pump! What is OpenAPI and what is the URL we need to specify? I guess it will be some JSON/ReST end-point kind of thing where we also have the option to pass authentication (None, Basic, OAuth) which I leave out of scope for now. So, next step is to have that URL available, but for that we first need to know more about OpenAPI:
- OpenAPI initiative
- Swagger specs
- Sample JSON; Retrieved from OpenText support…Thx!
- More samples; After research…
During my exploration I ran into some interesting public open APIs (just for the future!)
So, the world of public non-authenticated Open APIs is at our feet…Now we need to choose one! We require to use a “Specification URL”; In other words the “schema definition” of the OpenAPI end-point. Let’s start with
https://petstore3.swagger.io/api/v3/openapi.json; Fill it in the specification URL field and hit ‘Generate API’! It’s a party…
Boy-O-boy…That’s a lot of boilerplate code! I thought my EIS connector was advanced yet, but we only scratched the surface last time! On the other hand, this also has to do how advanced the specification is. Let’s see what a simple YAML example does:
https://raw.githubusercontent.com/OAI/OpenAPI-Specification/main/examples/v3.0/uspto.yaml…It’s not that different!
I also tried other examples, but it must be pretty specific as other samples gave a null pointer or still inform you about a Non-OpenAPI specification URL. So, after this try-out session, I end up with 2 questions:
- How to build it you own? Well, I recommend you follow this, this, or this.
- Generate “external” entities? That’s the next step on EIS where you require a new document of type ‘EIS Repository Reference’, but that’s (for now) out of scope for this post…I just created a new backlog item for a full implementation on the “new way” of EIS connector usage.
- Can we publish this already? Nope, as it requires OpenAPI specification libraries on the server; Have a look at the ‘Dependencies’ tab of the generated ‘Java Archive Definition’ file in the project:
I also explored the code a little, but you still need to implement the real calls to your external system. So, keep in mind its boilerplate code based on an OpenAPI schema definition!
GIT as Source Control Management – Beta version
I couldn’t find a feature flag for this one, but it looks like we need to deploy a special CAP package! So, we move to the
/system with the platform
sysadmin account where we dive into the artifact ‘Application Deployer’. Find yourself the ‘GIT’ package and run an ‘Express Deployment’:
Now what? Well, how about a new workspace in your own organization with Git source control selection:
Ohw yeah…!! NICE!! Now for that next screen:
- I use the public GitHub repository found here
- You need to initialize the repository with minimal one branch;
mainin my case.
- Read this PAT information on GitHub to get one for the authentication.
My connection is valid…Hit next, and ‘Create’…
You end up with an empty workspace (without a project). This is because the git repository was only initialized with a ‘Readme.md’ file (as recommended by GitHub). So, create a new project yourself, with a folder-structure, and create your first entity. When done, we make the changes available:
How smooth…Have a look yourself: https://github.com/HetBenkt/AppworksGitTest
Question, questions! Yes, I know…I asked the same questions about the locking principles of the platform. With Git this is still the case, but for a reason!…Git works with a local repository and a remote repository and needs to merge code eventually. Only, we’re not in control of the sources of our solution; The platform is in control! Merging code is most of the time a manual task to do, because only your team members know what is changed. With generated sources it’s an impossible task to do, so we’re more save with a lock and communicate with the developers in your team…Yes, my friends! Developers can communicate, and we’re lucky OpenText did not remove it from doing so! 😉
How about the local/remote repositories? Well, I didn’t do a deep dive, but I think it’s a direct lock in the remote repository reading this thread on stackoverflow…Don’t pin me on it as it already does the solid trick for my purposes…Over and out…
‘OAuth’ support for HTTP Connector
YES, our request is granted! Do you remember this post; It covers the extension of the RestRequestHandler…This extension was done for a reason! Implementing OAuth-support was one of them…We did it for several customers, but not anymore with the new “client credentials flow”
Time to first follow my own post on consuming ReST data with the HTTP connector…
…A few moment later…
HTTP Connection Manager once more and see the new OAuth support passing by:
Keep the mentioned “Advanced Development Guide” as a reference to make the ‘Authentication’ a fact as that’s out of scope for this post…There is more on our bucket-list for the 22.3 release!
HINT: There 2 posts also working with OAuth which can help you on your way…
Subversion 1.14 LTS support
Sure…why not!? Have also a look at this subversion release notes page and “git” yourself informed about the latest release since…
May 27, 2020! YOLO! 🙈 🙉
Email Connector mailboxes poller password
Remember this post? Have a look again in the email box configuration XML…Yes, you’ll find yourself a plain text password. It’s not that bad, and you need to save it somewhere. It looks like this password (#RTFM) was sent to the client in a password element (somewhere in the HTML code viewable with the
F12 developer tools). I haven’t tried it out myself, but I trust on the “blue-eyes” of OT that it’s solved now.
Support to mark a ‘ToMany’ relationship as mandatory in a form
An image tells a thousand words:
From a runtime perspective, you are notified with a message on what your valuable end-user is doing wrong:
When you read the grammatically questionable message, your end-user will understand the intention!? As a developer, I understand how hard this can be…So, fair enough! 🤔
Configuration to enable browser spell check in Rich Text presentation and emails
Haha…Read that last comment from the previous section!? 😣 Why not using the browser spell-checker also for the messages? Isn’t that the world being up-side-down! 🙃
Ok, it’s getting hot in here…
Well, rich text fields are related to a ‘Long text’ type of property, so I just create one and place it on the ‘Create’ form of an entity. Publish into runtime and double-check!? Nothing…#RTFM! It’s “not enabled by default“! Sure, to enable it we require to change a fancy
config.js file; part of the third-library with name ‘CKEditor’!? Hmmm…Would it be this file:
/opt/opentext/AppWorksPlatform/defaultInst/webroot/shared/thirdparty/ckeditor/custom/config.js? Available through this URL:
From the developer console, I see also these parameters passing by in the URL
?direction=ltr&controlHeight=266&language=en-US&baseURL=http://192.168.56.107:8080/home/appworks_tips&t=M2G9. Just for my registration for whenever needed.
Also interesting as background to know: “WYSIWYG editor of tomorrow, available today”
Here our feature is described in more detail…directly from the “fire-pit”. 🔥
vi /opt/opentext/AppWorksPlatform/defaultInst/webroot/shared/thirdparty/ckeditor/custom/config.js. Update the file with this flag:
config.disableNativeSpellChecker = false;
…Are the underlined red words THE ones found? I guess!? Comment me if this is the final conclusion!? Well, I don’t know how usefully this is. Now I understand why that previous mentioned message passed the grammar test! 🙄
!!Almost forgotten!!…Composing an E-mail via the related building block on entity level, you have the same support for this “great” feature!
Text formatting options for hyperlinks in forms
Nothing more, nothing less…next one please!
Form Building block enhancements
Again a screenshot to start with where we can now select the “View” layout for a ‘to many’ repeating group / grid:
When you don’t select anything it will use the ‘old’ behavior which is using the layout marked with the option ‘To view items in full screen’ on the related entity…duh!
From the same right-panel there is another option feature available. This makes it possible to let users select a form/layout:
In runtime this option looks like this:
Nice, I understand customers would like this option…Where else did I see this option? Yes, in release
20.4 we saw a same feature passing by in the advanced properties of the ‘List’ BB!…Have a look yourself if you missed it!
#RTFM Note: In the runtime ‘Create’ dialog box, the repeating group container and grid only support forms configured to create but not the layouts…Sounds logic to me.
Improved responsiveness in forms using sections
“Section” creation is now also available for regular containers and tabbed containers:
Well, it is what it is. It will help to reduce white spaces in it. On the other hand…Can’t we make this much better with predefined layout managers? I’m a proponent on JavaFX where we can use responsive layouts for years. Tip for the future? Here is another layout option from a Vaadin perspective
There is more on responsiveness…Grids, sub-forms, containers, and tabbed containers will be more responsive in runtime! From a designer perspective you have the option to ‘auto resize’ on those components once dropped into a section!
Set an application language in the User profile
An interesting option which is working smoothly:
I only selected my native language, did a refresh of the page and directly saw the change. Not fully, but that’s because the ‘real’ language pack is missing. Have a look at this post on using a language pack.
Italian language support
Check! The Italians will love you…🍕
Metering of transactions in AppWorks Platform
I’m not a sales guy, so I don’t care about licensing models!? What I do care is about a so-called service account!? I never used it, and I was required to get a view in the administration guide of the platform with a related section for this feature called “Viewing metered transaction information”.
First you require a service account…Created in OTDS with the property
oTExtraAttr9 set to TRUE! Let’s follow the steps from the manual.
- Login to OTDS
http://192.168.56.107:8181/otds-adminwith the account
- Go to the partitions
- Open the ‘View members’ of the partition connected to the resource of the AppWorks platform. In my case
awp. If you don’t have a clue…Read this first!
- From within this partition, create a new user like you would normally do. I use the account name
awservice(I also have
- Make sure the account never expires
- From the ‘User Attributes’ section, we apply the asked property:
- After saving the user in OTDS, it should consolidate automatically to AWP:
- I just apply the ‘Developer’ and ‘Administrator’ role and play a bit around under that new service account in runtime to generate some transaction data.
- To view the metered transaction data, we can log in to the
/systemspace with our
- Here we open the ‘License Manager’ artifact
- Click the ‘View’ button and double-check on the metered transaction data for the service account!
Don’t shoot the messenger on why the user is named
Documentum integration enhancements
Let me start telling that I don’t have Documentum up and running currently. I recommend to read this post to get a closer look. What is left for this section? Well, it’s great to see that the investment in connecting Documentum as a Content Management System to the AppWorks Platform is still on the priority list at the OpenText AWP product team; Especially, with my background as DCTM consultant.
Let’s give an overview from what was added last couple of releases for this connector (incl. this release)
||Document renaming||‘File’ and ‘Content’ BB get a new ‘Rename’ action; DCTM is updated too!|
||Document version types||Default is minor, but user can select major too|
||Icon for checked-out document||A visual indication on the checked-out document|
||Cancel checkout||Revert a checkout action|
||Dynamically show/hide content actions||Based on the state of the document|
||Metadata support for ‘File’ BB||This is during the uploading of files|
||Editing documents without rendition||Downloads the content for a seamless editing experience|
||Basic authentication support||Depends on your DCTM version in use|
||Edit documents using native applications||In 22.2 we also get a seamless editing update|
||Basic authentication support||Depends on your DCTM version in use|
||Zip and download one or more documents||Who doesn’t want to do this?|
||Mandatory properties||Seen from an AWP runtime perspective|
||Add multiple Documentum types with a default||During content upload you can select the DCTM type|
||Rendition support||So, when a PDF rendition is available; it is shown|
Keep up the excellent work…It’s highly appreciated at the Documentum customers also using AppWorks. The best of both worlds (in my opinion!)
Manage Kubernetes secrets with External Secrets Operator in a container-based deployment
The feature speaks for itself and people collaborating with it will see the benefits, but man! Kubernetes, Kubernetes…What should I do with it. I totally understand the principles, I do understand its power, and I did a nice Kubernetes Helm-charts session to see if I could get the platform up and running (FYI: it failed but was my lack of knowledge…It’s still on the backlog).
What I do not understand is why we’re trying to push a large monolithic application (which AWP is) into a containerized box!? Please, comment me on this one! The only advantage I currently see is at a service provider level where the provider fully automated the delivery of AppWorks platforms to all its customers with options to add an OTDS, DCTM or OTCS instance (and other related software components like Brava! or IV).
Is it still that interesting for a normal simple company which only requires one platform, with one organization to work with? Even double executed? Well, maybe if you already have a Kubernetes knowledge team on-board, but otherwise? I don’t think so. What I do see, is the move from on-premise servers to a cloud-based provider where we install the platform on dedicated VMs. If you use the silent installation options, you can automate a lot of actions, and you don’t have all the Kubernetes overhead to dive into…That’s how I see it…Again…Comment me!
1.9 support…Upgrade to
1.10 or better
1.14 LTS. Who wants to use subversion anyway when we now have Git support? 😎
That’s it for the new release…Playground 22.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 2022 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”?