Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

During an interesting AppWorks community session (initialized from OpenText), we got some more insight on how the XML datastore (XDS) works with XML data. I wrote before about XDS, but this time we get a better understanding about the different levels of saving/creating/reading XML data in this storage location. Why? Well, because it was unclear for me at that moment in time; pieces just fall into place with good examples and teaching you what I experience myself!

Let get right into it…

These are the three levels am I talking about:

1. Independent Software Vendor; When an XML document is stored in the system space, deployed from third-party CAP packages. These will be the CAP packages from the platform (where OpenText is also third party), but also when you deploy your ‘Shared’ CAP package into that same shared/system space! Have a look into your project package properties where you can define where your package can be deployed in the section “Supported Deployment Spaces”.
2. Organization; When the XML document is stored in the organization space. So, this can happen after a publication from your development organization, but also when you deploy a CAP package into a specific organization!
3. User; This is a manual action on an organization-level XML document; Explicitly done in the XMLStore. It’s possible to package this user-level XML document as well for your solution, but in that case you first need to publish it as organization-level document (which is the default), manually save it as user-level XML document and then create your solution specific CAP package.

Also keep these principles in mind:

• ISV-level: You can create a new organization-level and a new user-level
• Organization-level: You can only create a new user-level
• User-level: You can only create a new organization-level

We learned already that this XML data is eventually saved in the database; So, it’s interesting to monitor your database with these statements:

1 2 3 4 5 6 7 8 9

SELECT * FROM xds_document WHERE NAME = 'test.xml' ORDER BY lastmodified_date DESC; SELECT * FROM xds_document ORDER BY lastmodified_date DESC LIMIT 100;

…

With this intro, it’s time to build something nice to get this screenshot where all 3 layers are available for the same document:

The screen is from the ‘XMLStore Explorer’ in the ‘System’ organization…The ‘Shared’ space! These are the steps (find more details in this post as well):

1. Create a new workspace and project in your specific organization (not in ‘/system’!)
2. Create a new xmlstore folder and set as ‘Start Point of Qualified Name’
3. Add a subfolder custom
4. Add a new document of type ‘XML Store Definition’ in the root of the xmlstore folder; I name it xsd_custom
5. Add a new test.xml XML document (with just the empty <test/> element) in the custom subfolder
6. Publish it, and you will see the document in the ‘XMLStore Explorer’ artifact; Under the custom folder; The level is ‘Organization’!
7. Now create a CAP package out your project which is deployable under both the shared and specific organization spaces
8. Deploy the CAP package in the ‘Shared’ space; You can deploy this package from the ‘/system’ organization using the ‘Application Deployer’ artifact and selecting the ‘Shared’ space
9. After deployment, open the ‘XMLStore Explorer’ artifact in that same ‘/system’ organization and have a double-check on the ISV-level for your XML document. With a right-click you can now create an organization-level version and also the user-level version matching the screenshot from above.

What can we do with these levels of deployment? Well, you can read its data for the given level. WHAT!? Yes, keep on reading…I first make sure to update my test.xml files (directly in the XMLStore) with a slight nuance in data to see any differences for the below calls. After the update, from the ‘System’ organization, I open the ‘Web Service Interface Explorer’ and get an overview of XMLStore related services searching for namespace http://schemas.cordys.com/1.0/xmlstore:

Now evaluate the ‘GetXMLObject’ service with this SOAP-request:

1
2
3
4
5
6
7

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP:Body>
    <GetXMLObject xmlns="http://schemas.cordys.com/1.0/xmlstore">
      <key version="">/custom/test.xml</key>
    </GetXMLObject>
  </SOAP:Body>
</SOAP:Envelope>

You will conclude it will receive, by default, the user-level instance (not the organization-level as found in the documentation!?) of your XML document…correct? Now for the other two levels…How to do it? Well, it’s really simple…Just set you level in the version attribute of the key element of the request; Like this:

1
2
3
4
5
6
7

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP:Body>
    <GetXMLObject xmlns="http://schemas.cordys.com/1.0/xmlstore">
      <key version="isv">/custom/test.xml</key>
    </GetXMLObject>
  </SOAP:Body>
</SOAP:Envelope>

Valid values are isv, user, and organization. The documentation tells me when it finds nothing, it will search higher in the level tree; My experience is that it will just receive nothing at all. Just an empty response element after I deleted my user-level test.xml document from the XMLStore manually.

And that’s all I wanted to broadcast for this post! 🎙 😁

…

Just a final note…One thing I didn’t try is the following as I see ISV XML documents in my specific organization, but how did they get there? Well, my theoretical explanation sounds like this: Those XML documents should have their origin from the ‘System’ space, so I think a CAP file is generated from data in the ‘system’ space and this CAP is deployed into the specific organization. That concludes me the OpenText/Cordys specific packages are crafted in the ‘system’ space!? Or do they get an ISV flag differently during an organization specific deployment from a platform installation perspective!?
I tried the scenario where I created a CAP file with XML documents from my specific organization; After deployment in another organization, I always see them at organization-level in XDS, never as ISV-level. The ISV-level only happens when I deploy my CAP file into the ‘Shared’ space, but then I don’t “see” them in my specific organization!? You get my point…correct? Well, if you know the answer…comment me as I already had enough joy on my own try-outs! 😋

That’s it; A “levelution” DONE this time! We exposed interesting insights on the XMLStore with new queries, webservices, artifacts and on top of the cake a cherry to scope it all down to a certain level of usage. Interesting stuff, and now you also know how it works…Have a great weekend, and I see you in the next one!

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