Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
This is the correct moment in time to upgrade my old CentOS 21.1 AWP VM to a newer 22.2 version. Why? Well, because I already moved from CentOS to RHEL, and I’m left with a legacy image! Before I remove the VM instance, we just execute the upgrade procedure on this VM…How hard can it be!? Just follow the documentation instructions!? 😅 The 22.2 features are already explained in this post…
I know we’re already on 22.3 with the platform, but that doesn’t break the “party-vibe” for this post!
Let get right into it…
Time to follow the OT AWP 22.2 Upgrade Guide which is also delivered with the software package. From experience, I know preparation is key!
Think, before we act is a requirement during the upgrade of the platform. So, this is the time to validate our current situation and double-check the ‘22.2 Supported Environments’ PDF on any mismatches! Spin up your VM where AWP 22.1 is fully up and running in combination with an OTDS instance for default authentication.
I leave the upgrade of OTDS out of scope for this post! I already made a note in this post about the required tomcat version 10, database back-end to save data, and the missing ‘opendj’ service!
We log in to the VM with the terminal tool ‘MobaXterm’ and execute a list of commands to verify our current installation. When a mismatch is found, you need to produce a plan to fix it:
|Part||Command||Result from 22.1 VM|
Just for my registration: The ‘slapd’ command required me to update the ‘LD_LIBRARY_PATH’ variable:
In my case there is no mismatch found, so this should be an easy upgrade! 😉
Time to follow the upgrade manual and highlight the required tasks for my specific VM…Apply the tasks for your own environment; they are straight forward. Make sure to use the
sysadmin account; This is a platform account which we can use to log in without any OTDS authentication in the ‘System’ shared space:
✅ Administrator rolled account for all organizations with ‘System’ as default
Well, I log in to the system space with my
sysadmin account. From the ‘Organization Manager’ artifact I can clearly see my platform account is administrator for all my organizations (incl. the ‘System’):
✅ Check availability of the account
All specific organizations (excl. the ‘System’) require this account from a ‘User Manager’ artifact perspective. I always connect OTDS to my organizations, so this account is already consolidated to my organization from an OTDS perspective!
✅ Disable OTDS as default authenticator
I connect OTDS only to my specific organization! From this perspective, I can disable the OTDS default authentication from the ‘Security Administration’ artifact:
✅ Run the tool
Just a tool from the CWS-CLI-set-of-tools. Read all about it in the ‘Advanced Development Guide’! I know the struggle, so I follow my own post on the CLI to make it come alive with these calls:
max_locks_per_transaction for PostgreSQL
Interesting, as I already faced its limits during a previous 21.4 installation!
sudo vi /var/lib/pgsql/11/data/postgresql.conf
There is more on the checklist in the documentation but does not apply to my specific image; I don’t have SVN connected; I use the default service containers; I have a simple one-entity project.
Cover Your Ass with a CARS / OpenLDAP backup!
I couldn’t find it in the upgrade manual, but I saw a failure after my first upgrade (as preparation for this post!). So, in quick steps:
Make sure to do a final check on CARS before running the upgrade:
- Check CARS service status on a correct running service:
systemctl status cars-slapddefaultInst
- Make a connection with ‘JXplorer’ to verify!
Now it’s time for that next step…
Make sure the installation packages for the platform are available in the VM like we would normally do for an installation. My starting point is this path:
cd ~/opentext-appworks-suite-22.2-linux/OpenTextAppWorksPlatform/. Make sure to have X11 correctly configured, and you should be ready to run the next couple of command:
chmod +x OpenText_CARS_2.7.bin
The CARS installation wizard starts, and we can just follow the steps like we normally would do. We should see some extra screens matching our upgrade procedure. Starting with the first screen like this one:
Continue the wizard with a final summary where we can hit the ‘Install’ button:
In the end, we can hit the ‘Done’ button:
#This last logfile gives me an error: `STDERR : /opt/opentext/cars/defaultInst/temp/carscontent.ldif: No such file or directory`
#A search for the file didn't give any results: `sudo find / -name carscontent.ldif`...Strange...Comment me if I miss a clue!?
So, you see I have an upgraded CARS instance, but there is no content inside it (you can recheck with ‘JXplorer’)! This was not as expected, but that’s why I made a backup. Time to restore our backup into the upgraded CARS instance. After this we can recheck ‘JXplorer’ with a valid response! 😅
Let’s also check our service with a daemon-reload:
Everything “smells” fine! So, CARS is done; next step…
All right, back to
cd ~/opentext-appworks-suite-22.2-linux/OpenTextAppWorksPlatform/ and give the magic command (learned in this post):
sudo CATALINA_HOME=$CATALINA_HOME CLASSPATH=$CLASSPATH ./OpenText_AppWorks_Platform_22.2.bin
Just follow the wizard like we always do with the upgrade option, and hit ‘Install’:
In the next steps you are required to provide the database credentials and in the end you can hit ‘Install’ again from the summary page:
Time for coffee…☕, and when I’m back it’s done:
Looks all fine…Next step…
The AWP node/instance is upgraded, now it’s time to update the packages on it. We can do this with a familiar URL:
http://192.168.56.107:8080/home/system/wcp/cap/install/?nodeName=appworks. Yes, that’s the same URL when we install an image from scratch! Have a look in this post for any reference.
I just follow the flow:
- Login with
- Deploy the ‘UPGRADE’ operations
From experience, I know it’s now the time for a long lunch-break…
When back…hit the ‘Finish’ button in the wizard, and you are provided with the upgraded login page:
Well, where are you waiting for…Login to the ‘System’ space with the
sysadmin account and get noticed on our first upgrade detection:
Wait a minute, and finally you can close the ‘Upgrading CWS runtime repositories’ modal panel.
Nice…That’s all! Next…
Move to your own specific organization now. In my case
http://192.168.56.107:8080/home/appworks_tips/; we can enter this space with the
sysadmin account, but we would like the use our OTDS
awdev again. So, open the ‘Security Administration’ artifact and restore the default OTDS authenticator:
Sign out from the
sysadmin account, and you are (by default) redirected to OTDS again…Time to login with
awdev. After login, we can enter the ‘Workspace Documents’ artifact which prompts you with another upgrade message:
Make your choice, and hit next…
Time to open our ‘Workspace’ and continue our lives where we left…
Double-check in the ‘About’ artifact:
Niceeee…Finally, a “DONE” on the AWP upgrade topic of my backlog! Was it hard to do? Not at all! Is this everything? Well, not completely! The upgrade documentation contains a chapter on post-tasks, but I leave those with you for your own environment. My environment is kept simple, so I’m able to show a basic upgrade procedure. I guess you can make your own conclusion on a sufficient knowledgeable upgrade post with a head start on any upgrades in the future.
What else is out of scope for this post, but is as important to keep in mind?
- Do a “clean build output” on your solution and re-publish the projects
- Upgrade the Published Source Layer which relates to BPM instances to show information in the PIM. This information can get out of synch because of the large data set. You can upgrade this data per BPM from the ‘Deployed Process Models’ artifact in the ‘System’ space (only!)
- SVN version upgrade when your solution is attached to it (as recommended)
- Customizations which depend on the platform dependencies (upgrade the dependencies in your local IDE)
- Upgrade your OTDS instance (incl. Tomcat)
- Upgrade your connected CMS (like OTCS or Documentum)
- This post shows an in-place upgrade, but you can also do a parallel upgrade and do a migration after it…It’s all up to you!
Have a great upgrade weekend, and I CU in the next one…