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!
- 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…
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.
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)
Well, the server itself contains off-course the installation location in
%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! 🤔
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:
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:
This query tells me there is an
XMLStore folder-structure for each user:
Ohhh boy…It looks like we just exposed a whole new episode on database explorations here!…That’s for another time! 😲
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:
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?
SELECT name, content
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!? 🙈