Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

PSL, PSL, PSL…There we are again! (Published Source Layer). I thought I would have known it after all my experiences, but I found out there is more to explore. I hit the wall of resource limitation, and it all has to do with PSL content, as after cleaning it the road was an unbroken boulevard of green lights. Still, my actions kept me thinking why we do all this PSL-stuff, and this post is (hopefully) the outcome!

Let get right into it…

Time to build ourselves an easy one-step BPM template in our project looking like this:

Save it (in the bpms folder of the project) and close it. Now the great question…Did we do any PSL already? Well, only one way to find out (I think; Comment me if we can do this smarter).

Right-click the project and create a new package:

After package building, you can download the CAP file:

Now, let’s open this file with the tool 7-Zip and watch the insights (like a surgeon would do!)

Have a look at this file .\aw_tips prj_generic 1.0.0.cap\pslContent\pslContent.xml

Your file can have a different name based on you project settings, but the PSL content is still there IF you have an out-of-the-box installation…Continue the read on this!

What you’ll find in the file is a lot of <Instance> elements (in my file 11 items which I reordered in this list because of the ‘typeVersion’ attribute!)

• Project details
• Full details of the crafted BPM
• Something with a qualifiedNameRoot (not for now…)
• Overall BPM metadata
• Overall BPM metadata (with a ‘typeVersion’ attribute)
• The ‘Start’ of the BPM
• The ‘Start’ of the BPM (with a ‘typeVersion’ attribute)
• The ‘Activity’ of the BPM
• The ‘Activity’ of the BPM (with a ‘typeVersion’ attribute)
• The ‘End’ of the BPM
• The ‘End’ of the BPM (with a ‘typeVersion’ attribute)

I’m not sure if we can call this XML BPML-notation!?. I did a quick build in bpmn.io and did an export of it as compare; Well, it has similarities on definition level….Interesting! I leave this with you as a weekend task on your own.

Watching closely at the pattern, you start to see some versioning going on here as the ID of the ‘typeVersion’ attributes are equal! AHA-moment. 🤔

Let’s recap this moment with a new BPM and after creating that activity, have a look at the undo slider:

Again, I’m not sure, but I bed this has a direct relation…comment me!

We’re not saving this new BPM; We move back to the previous one, add a second activity, and do a save (which makes it an updated version!)

I do the weird flowing of lines because I don’t want to garbage the PSL outcome!

I now do a clean build output on the project with an increase of the build number for the package properties:

After re-packaging this new build; guess what!? Yes, I get 2 new elements of <Instance>; One with a ‘typeVersion’ attribute. Great…We can go on and on like this, but let’s say you have about 10 developers building on 100+ BPMs releasing each quarter; Imagine how this will look like for your PSL data…Yes, it’s massive!

For the packaging I haven’t seen a resource issue yet (but my package is not large), but for the deployment of a CAP to a different organization, I already hit the wall of my available resources (see the introduction).

…

Let’s jump into the ‘/system’ space (with the sysadmin account) and do a first deployment of the latest package in the ‘Shared’ space via the ‘Application Deployer’ artifact:

I would normally recommend having a second organization available; Like for example appworks_tips_deploy as a second option on the same VM. This is something your administrator can do from the ‘Organization Manager’ artifact in the ‘system/shared’ space. You as a low-code developer also need to make this setting in the package properties of your project…A thing I didn’t do! You got me! 😊

Follow the wizard, and you will see this screen passing by:

Once you deploy the solution, you will also see the PSL data deployment:

Nice, but can we skip this during deployment phase once the data is toooo big to manage during deployment? OR if we simply don’t need it!?

Configuration and the result

Enter your AppWorks server via (in my case) MobaXTerm and edit this specific file: $CORDYS_HOME/components/cws/config/cws.properties

At the end of the file add this line: development.publish.to.psl.enabled=false

After a restart of the platform (systemctl restart tomee), we go back to the ‘/system’ space again. Open the ‘Application Deployer’ artifact and undeploy your package:

Don’t do this on production…It will also clean your runtime entity instances!

Just follow the wizard and finish it once you followed the undeployment flow. Great, we’re back from where we started. Time to do a redeployment again on our valuable package and guess what!? The ‘pslContent’ gets still a deployment!? And Yes, I did it also with a fresh package! #RTFM

So, this is only publication phase and not deployment phase…Time for a different approach!

The section “FYI: Auto deploy the PSL data” in this post is hereby “busted”!

…

Hint from the forum: In the same cws.properties file, we can also add another flag: exclude.psl.from.package=true

Guess what it’s doing? Watch the output of my new versioned package:

The ‘pslContent’ folder is not even there…Nice, we’re learning something here! The great question is still weather you want this or not!? That’s a decision for you to make!

What I also tried is creating a package including the PSL data and removing the folder with 7-Zip from the CAP file…The outcome? Well, it still finds the “deleted” PSL data, but after removing the below entry from the manifest.xml in the CAP, it nicely deploys which makes us more in control ourselves.

1
2
3
4
5
6

<!--This is the part I removed-->
<Artifact typeID="com.cordys.cws.deploy.pslcontent" name="pslContent.xml" id="...">
    <Lastmodified/>
    <Hash type="SHA1">1eff8816783195279cd4e26c90897531a972dc6a</Hash>
    <ItemPath>pslContent/pslContent.xml</ItemPath>
</Artifact>

I find this last action better although removing all the <Instance> elements from the pslContent.xml also did the trick.
…
Ohw, and don’t comment me on the difference in flag-naming where one flag uses .enabled= and the other one is not!? That’s inconsistency…agree?; #SUPPORT

…

Eventually, I also did a search for this exclude.psl.from.package property to get a clear understanding and if I can find more; Again, I stumbled upon the same class in file opt/opentext/AppWorksPlatformCE/defaultInst/components/cws/cws.jar. More specifically class com.cordys.cws.internal.settings.SettingsManager.class

AND what did my eye catch…com.opentext.cws.psl.async.deploymentandupgrade with a default value true…Would it or would it not!?!? Let’s try it by adding it to the cws.properties with a false flag: com.opentext.cws.psl.async.deploymentandupgrade=false

Restart TomEE, create a package (incl. PSL), and do a deployment…Nope, it still deployed the PSL data. Well, I already have my answers. I leave the other “undocumented” settings with you to try out. Have a search yourself and see also these kinds of settings passing by:

• com.opentext.cws.psl.deployment.behaviour=onDemand
• psl.isvp.install.timeout=PT6M

If you’re the genius having an overview of all these option incl. a valuable description…I suggest letting the community know!
It’s highly appreciated, and we’ll have a beer together; Or some wine! 😁

Where can PSL help?

In my circle of experts, I had a quick discussion on why we need PSL data and what exactly is PSL data. First an answer to the last question. It’s BPM template information about the build structure of the BPM (incl. the versions of it…as far as I get it but comment me); Think about information like activities, flows, xml-contracts, global settings, messagemap details, everything. With this information (answer to the “why”-question) it’s possible to reconstruct a new graphical view for an instance for you to further investigate in your production environment (again, including old versions of the BPM template)! From a developer perspective the PSL data is also related to the “undo” slider in the BPM editor.

See a detailed example of PSL data with explaining comments in this post.

The conclusion of the discussion (and thank you for the people challenging me!)…You need PSL AFTER packaging when:

• You want to use the graphical view to get an overview of you BPM instance (also for instances of an older versions of the BPM template!)
• You want to move steps back, manipulate the messagemap, and continue life on a failing BPM instance! There I have my AHA-moment again as I wasn’t aware of this possibility…I never used it, but I’m a developer, not an administrator!

Correct me if I’m wrong, but when we don’t need the graphical view of the BPM (because you have sufficient details on the messagemap on a failing BPM instance) AND you don’t need to revert anything because the dev-team made it all soooo smart (in a “wet dream” world! 🤣) that a full restart is sufficient to solve the problems, then…and only then you don’t need the PSL information! OK…AND when you don’t have any BPM instances (yet) on your PRD environment, but that’s a percentage of zero.

A great PSL informed “DONE”! Again, with interesting insights on the PSL terminology which gets clearer by each post and collaborations I’m involved in. As a low-code developer you need to understand these principles and see the “why” behind the choices you make for the platform. It’s off my bucket list for now and you benefit from it…Have a comment during your greatest weekend; I see you next week. Cheers.

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”?