Export Mania 2017 - Tag and Task

Warning: this post makes the most sense if you've read the previous post....

If I use the thick client I can tag one or more records and then execute any task (I prefer to refer to these as commands, since that's how the SDK references it).  In this post I'll show these tasks, the output, and how they may (or may not) achieve my goal.  My goal being the export of a meta-data file with corresponding electronic documents (where the file name is the record number).

The commands we can execute include:

  1. Supercopy
  2. Check-out
  3. Save Reference
  4. Print Merge
  5. Export XML
  6. Web Publish

If I tag several records and then initiate any of these commands, I'll get prompted to confirm if I'm intending to use the highlighted item or tagged items.  You can suppress this by unchecking the checkbox, but I let it alone (so there's no confusion later).  Once I click OK I can see the dialog for the selected task.


As you can see below, the supercopy command let's me save just the electronic documents into a folder on my computer or my offline records tray.  The resulting electronic documents are titled using the suggested file name property of the record(s).


The resulting files contain just the suggest file name.  It does not include record number, dataset id, or any additional information.  I also cannot get a summary meta-data file.  So this won't work for my needs.


Check-out does the exact same thing as supercopy, but it updates CM to show that the document(s) are checked-out.  Since emails cannot be checked-out, this task fails for 2 of my selected records.  That means they won't even export.  


So supercopy and check-out don't meet my requirements.  Next I try the "Make reference" feature, which gives me two options:

Here's what each option creates on my workstation...

Single Reference File


Multiple Reference Files


When I click the single reference file Content Manager launches and shows me a search results window with the records I tagged & tasked.  The multiple reference files all did the same thing, with each record in its' own search results window.  In both cases there are no electronic documents exported.

Single Reference File


Multiple Reference Files


Now I could craft a powershell script and point it at the results of my reference file(s).  The reference file includes the dataset ID and the unique record IDs. As you can see below, the structure of the file is fairly easy to decipher and manage.

Single reference file format

Single reference file format

I don't really see a point in writing a powershell script to make references work.  Next on the list is Print Merge. As shown below, this is a nightmare of a user interface.  It's one of the most often complained about user interfaces (from my personal experience).  The items are not in alphabetical order! 


It's funny because this feature gives me the best opportunity to export meta-data from within the client, but it cannot export electronic documents.  So I need to move onto the next option: web publisher.

The web publisher feature would have been cool in 1998.  I think that's when it was built and I don't think anyone has touched it since.  When I choose this option I'm presented with the dialog below.


I provided a title and then clicked the KwikSelect icon for the basic detail layout.  I didn't have any, so I right-clicked and selected New.  I gave it a title, as shown below.


Then I selected my fields and clicked OK to save it.  

When I selected the new basic layout and then clicked OK, I get the following results.  Take note of the file naming convention.  That makes 3 different conventions so far (DataPort, Supercopy, Webpublisher).


Opening the index file shows me this webpage...


I'm pretty sure the idea here was to provide a set of files you could upload to your fancy website, like a city library might do. I tell people it's best for discovery requests... where you can burn someone a CD that let's them browse the contents. 

Time to move onto the last option: XML.  When I first saw this feature my mind immediately thought, whoa cool!  I can export a standardized format and use Excel source task pane to apply an XML map.  Then when I open future XML exports I can easily apply the map and have a fancy report or something.  I was wrong.

Here's the dialog that appears when you choose XML Export... I pick an export file name, tell it to export my documents, and throw in some indents for readability.  Note the lack of meta-data fields and export folder location.


Then I let it rip and check out the results...


I would gladly place a wager that these 4 different naming conventions were created by 4 different programmers.  The contents of the XML isn't really surprising...

<?xml version="1.0" encoding="ISO-8859-1" standalone="no" ?>
<TRIM version="" siteID="sdfsdfsdfsdfd" databaseID="CM" dataset="CMRamble" date="Sunday, October 15, 2017 at 10:46:50 PM" user="erik">
  <RECORD uri="1543">
    <ACCESSCONTROL propId="29">View Document: &lt;Unrestricted&gt;; View Metadata: &lt;Unrestricted&gt;; Update Document: &lt;Unrestricted&gt;; Update Record Metadata: &lt;Unrestricted&gt;; Modify Record Access: &lt;Unrestricted&gt;; Destroy Record: &lt;Unrestricted&gt;; Contribute Contents: &lt;Unrestricted&gt;</ACCESSCONTROL>
    <BARCODE propId="28">RCM000016V</BARCODE>
    <CONTAINER uri="1543" type="Record" propId="50">8</CONTAINER>
    <DATECREATED propId="5">20170928093137</DATECREATED>
    <DATEDUE propId="9"></DATEDUE>
    <DATERECEIVED propId="1536">20170928093449</DATERECEIVED>
    <DATEREGISTERED propId="6">20170928093449</DATEREGISTERED>
    <LASTACTIONDATE propId="21">20171015224650</LASTACTIONDATE>
    <LONGNUMBER propId="4">00008</LONGNUMBER>
    <MIMETYPE propId="82">image/png</MIMETYPE>
    <NBRPAGES propId="83">0</NBRPAGES>
    <NOTES propId="118"></NOTES>
    <NUMBER propId="2">8</NUMBER>
    <PRIORITY propId="13"></PRIORITY>
    <RECORDTYPE uri="2" type="Record Type" propId="1">Document</RECORDTYPE>
    <SECURITY propId="10"></SECURITY>
    <TITLE propId="3">2017-09-28_9-31-37</TITLE>
    <CONTACTS size="4">
      <CONTACT uri="6185">
        <FROMDATETIME propId="157">20170928093449</FROMDATETIME>
        <LATESTDATETIME propId="158">20170928093449</LATESTDATETIME>
        <LOCATION uri="5" type="Location" propId="155">erik</LOCATION>
        <NAME propId="150">erik</NAME>
      <CONTACT uri="6186">
        <FROMDATETIME propId="157">20170928093449</FROMDATETIME>
        <LATESTDATETIME propId="158">20170928093449</LATESTDATETIME>
        <NAME propId="150">FACILITY-HRSA-4647 (At home)</NAME>
      <CONTACT uri="6187">
        <FROMDATETIME propId="157">20170928093455</FROMDATETIME>
        <LATESTDATETIME propId="158">20170928093455</LATESTDATETIME>
        <NAME propId="150">FACILITY-HRSA-4647 (In container)</NAME>
      <CONTACT uri="6188">
        <FROMDATETIME propId="157">20170928093449</FROMDATETIME>
        <LATESTDATETIME propId="158">20170928093449</LATESTDATETIME>
        <LOCATION uri="5" type="Location" propId="155">erik</LOCATION>
        <NAME propId="150">erik</NAME>
    <REVISIONS size="0"></REVISIONS>

On the positive side, I do get the file name, title, and record number.  However, the uniqueness of this XML structure is for the birds.  I could craft a powershell script to tackle renaming the files and such, but I refuse to do so.  I protest the rubbish in this file.  Fly away little Xml document.... fly, fly away.

All this tagging and tasking helps me know my options for the future, but it also demonstrates clearly that I'm looking in the wrong places.  Unique requirements like these (exporting documents with numbered file names) means I need to either build something custom.  In the next posts I'll show several options for custom exporting.