Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

O-Boy, did I have an interesting discussion again with a colleague! It was a discussion about the runtime security you can set on certain types of documents; like documents of type BPM, Homepage, XMLStore definition, or Web Service Interface. A valid question was raised: Where is this runtime security saved and how to revert it back? Interesting! 🤔

Let get right into it…

Well, first-things-first! For these types of R&D assignments, I make sure my database is logging sufficient information to get an answer! Eventually, the database is the key-player in saving data. So, let’s enable it for my PostgreSQL database on my RHEL-VM:

1
2
3
4
5
6
7
8
9
10
11
12

#Edit this file and set the log_statement variable:
sudo vi /var/lib/pgsql/data/postgresql.conf

#------------------------------------------------------------------------------
# REPORTING AND LOGGING
#------------------------------------------------------------------------------
...
log_statement = 'all'

#Now restart the postgresql service and monitor the logging:
systemctl restart postgresql
sudo tail -999f /var/lib/pgsql/data/log/postgresql-{day}.log | grep -E 'UPDATE|INSERT|update|insert' -B 5 -A 5

FYI: I assume you already have an interesting project with a BPM to use for this post. Otherwise, it’s better to first create one before enabling all the logging.

Now, right-click a BPM type of document and set the ‘Runtime Security’ from the context menu like this:

Back to the database monitoring, and make a conclusion you see a lot of statements passing by like these:

1
2
3
4

UPDATE XDS_DOCUMENT(...)
insert into XDS_DOCUMENT(...)
--You will also start seeing these when BPM instances are triggered:
insert into PROCESS_INSTANCE(RUNTIME_DOCUMENT_ID, ...) values ('reference to XDS_DOCUMENT!', ...)

So, this is all about XDS documents! For these documents, we have an XDS storage location available…Tell me, tell me! 😀 Well, have I ever mentioned the ‘Cordys Management Console’ tool? Yes, the one you can start with a command like this: sudo sh /opt/opentext/AppWorksPlatform/defaultInst/bin/cmc.sh

This tools starts a UI from you Linux VM and therefor you need to set/export the DISPLAY variable to your local PC. I don’t cover it in this post; Have a look for notes here which also covers Azure VMs to show a UI on your local machine (via xauth) from what I experienced!

When you have the CMC-UI up and running, you can open the ‘Repository Browser’ from the left panel; You need to log in with the correct username/password and select the correct Data Source Object (DSO) to make a connection:

From this browser, you can dive into your workspace, project, and eventually your BPM. These are all XML documents where our BPM has a runtime security described in the element <SecurityDescriptor>:

Now, copy the ID and search for it (in the correct branch) from the top left ‘Search’ button:

You will conclude this is just a child document under the bpm_dummy document! 🙄 Only, now you know there is a search available in this UI! This BPMSecurityDescriptor contains more IDs to search for; these are also child XDS-documents under this file. After some research you will start to see it as a structure like this:

• BPMSecurityDescriptor/accesscontrolentries/uri/id. Points to ‘AccessControlList’
  • AccessControlList/identity/uri/id. Points to the role ‘Identity User’ definition (in the ‘CWS_Default_Metaspace’ branch)
• BPMSecurityDescriptor/accesscontrollists/uri/id. Points to ‘AccessControlEntry’ (ACE)
  • ACE/applicableRights/uri/id. Points to ‘ApplicableRight’
    • ApplicableRight/right/uri/id. Points to the permission ‘Initiate’ for the role (in the ‘CWS_Default_Metaspace’ branch)

Notes:

• Each applied role will get its own ‘AccessControlList’ XDS document
• Each selected permission will get its own ‘ApplicableRight’ XDS document
• So, each role has its own set of XDS documents
• Adding a self-defined role (like a new solution specific functional role), you will get an id pointer in this same structure where the AccessControlList is also found in your own workspace branch…Which is your self-defined role!

That’s all folks! A simple, but efficient post where you see how things work in the XML DataStore back-end for your runtime security. There is a lot more saved in this location, but I leave that for another post if you comment me on it. You see how easy it can be when you open your eyes on systems you think are closed from the outside world. Have a good weekend and till the next post, next week!

Ohw, almost forgotten!…Keep your database guy/gal your friend and disable that logging setting again! 🙈

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