Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

What I try to cover in this post is a long-lasting question I had on all the different storage locations the AppWorks platform uses. It’s not the external location like Documentum or OTCS I’m curious about, but more in terms of DB, CARS, XMLStore, XDS or the AppWorks server-disk itself. If you’re a seasoned ‘Dinosaur’ consultant, you probably know all this stuff out of your head, but there is one specific storage that never ‘snapped’ into my mind. After this post it will…get ready for an interesting post…as always!

Let get right into it…

To get a startup question: What storage locations do we even have in AppWorks? Let’s start simple!

Notes upfront:

• I leave the external locations (through the document store service container) out of scope!
• I also leave OTDS out of scope for this post which has a direct relation with our beloved platform, but not for this post…

Database

This is the location where AppWorks stores the “metadata” of the platform; Well, it’s between double quotes as later we’ll learn that XML data is also stored into this database. So, you’ll find data on your entity instances, BPM instances, lifecycle/case instances, audit data, and much more.

CARS

This location is an LDAP interface specifically designed to save AppWorks related “user/group/role” data. Again, with double quotes as if you ever explored CARS with the ‘LDAP Explorer’ artifact you will conclude it has also non-user entries like created/reused ‘Method sets’ and created ‘Service containers’ within an organization; this with a security mindset! This storage is also a separate installation with its own LDAP database (based on OpenLDAP)

Server itself

Well, the server itself contains off-course the installation location in $CORDYS_HOME (or %CORDYS_HOME% for the Windows delegation), but it also has paths to store things. Like the webroot folder to serve web-content to the end user, or the capcontent to upload CAP files for deployment, or the cws folder to sync your precious solution. There are many more interesting locations on the server for you to explore! 🤔

XMLStore

Our next storage is the one we can explore with the ‘XMLStore Explorer’ artifact. OpenText saves its own XML content to it (like the xForms in CAF-files), but we can also save XML files into this storage via an ‘XML Store Definition’ and we can even read XML data from this same store via a SOAP-service called GetXMLObject. Interesting stuff…read more here, but what is the physical location for this storage? Is it a separate database running somewhere magically?

…

After a quick R&D session and increasing the database log-level, I can conclude that this XML-part created manually in the XMLStore Explorer…

…gets eventually a save into our database!! WHAT? The location?…Well, have a session with HeidiSQL and make this statement:

1
2
3
4
5
6
7
8
9
10

SELECT document_id,
       NAME,
       created_by,
       type_id,
       parent_id,
       content,
       accesscontrolpolicy_id
FROM xds_document
ORDER BY created_date DESC
LIMIT 10;

When I follow the parent_id all the way to the top…Till I find a document not having a parent ID, I find a new type of document ID_TYPE_FOLDER. Just a statement that made me curious:

1
2
3
4
5

SELECT COUNT(document_id),
       type_id
FROM xds_document
WHERE type_id LIKE 'ID%'
GROUP BY type_id;

This query tells me there is an XMLStore folder-structure for each user:

1
2
3
4
5
6
7
8

SELECT document_id,
       NAME,
       created_by,
       type_id,
       accesscontrolpolicy_id
FROM xds_document
WHERE parent_id = ' '
  AND NAME = 'XMLStore';

Ohhh boy…It looks like we just exposed a whole new episode on database explorations here!…That’s for another time! 😲

XML Data Store (XDS)

Now for our final storage location! But where did we see this XDS? Well, have a look again in the queries of that last part of the previous section!…NOOO…Would it!? Yes, my friends…It’s indeed what you think, but there is another location where we can explore the XDS! Tell me, tell me; That is the Cordys Management Console (CMC)! Let’s have a view, and you see a save in this storage location:

Read more about that CMC tool here

What does this location store? Well, it looks like a copy of my workspace, project and related documents created in it! Interesting…It also looks like they are all glued together based on documentIDs. So, pick a document, copy the ID (starting with 0800...), and search it in the correct branch! Do I hear you say branch? Didn’t I see a table passing by in the database:

1
2
3
4
5
6
7
8

SELECT branch_id,
       name,
       internal_name,
       description,
       accesscontrolpolicy_id
FROM xds_branch
WHERE parent_id = ' '
ORDER BY NAME ASC;

Looks familiar…right? Now, for that great question: Can I find that selected document as XSD_DOCUMENT entry in the table and does it contain that same XML-part?

1
2
3

SELECT name, content
FROM xds_document
WHERE document_id = '080027c2-550f-a1ed-83c6-c9c2382b9b9d';

Well, looks like a hit to me! 🤠

NICEEE…Finally, an answer to my own questions and curiosity where AppWorks saves its related data! Eventually it’s just one ring that rules them all…That’s our database! So, did you already make friends with your database administrator? Well, ask him/her for a Friday-beer as this person will be your fallback scenario when things start to shake in the platform! We’ve exposed interesting information in this post on different storage locations, but always be aware that it’s not my first recommendation to hack into your database and manipulate data from this perspective; A quote from Spider-Man: With great power, comes great responsibility!. Have a great weekend…I CU in the next one!

Just to trigger your mind; A database column isn’t endless in size! What if the XML-part is larger than the column-width can take!? 🙈

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