Geolocations via Content Manager

in ,

Before I go through the trouble of writing more code, I should take a look at what's available.  Hopefully by reviewing each component I can make a list of features missing.  Then I can decide how best to cobble together my final solution.

Accessing Facilities via the Thick Client

When performing a search it is easy to specify that the results include the GPS location in both the view pane and the list pane.  Making the fields visible lets me peruse the data and verify I like the results.  There's no way for me to leverage that data here without a mapping interface.

 
2017-09-24_14-44-29.png

I can use the view pane's GPS Location hyperlink to browse to the location via the map connector.

 
2017-09-24_14-49-37.png

But that's it.  Only potential thing I see here is swapping out the static google map connector for one that embeds an iframe showing results nearby.

Viewing Facilities via Web Client

The out-of-the-box configuration of the Web Client does not support a grid style layout for meta-data in the search results pane.  As you select an individual record in the results, the right-hand view pane exposes a link to the location.  

 
2017-09-24_14-38-28.png

To modify the value you'd either get to the registration form via the update button...

 
2017-09-24_20-00-31.png

Or you click the GPS Location option from the Details drop-down button

 
2017-09-24_15-02-52.png
2017-09-24_15-01-35.png

That's it.  Nothing else to see here! :(

View Facilities via WebDrawer

Webdrawer is a no-thrills interface for the exposure of public records.  Using it implies (at least to me) that you don't care who the user is and you'll just be reading data.  That fits for my scenario, so let's see what's available.

 
2017-09-24_20-06-32.png

Entering "**" into the quick search box and pressing enter should result in all facility boxes being returned (I have nothing else in the dataset).  The search results page shows my boxes, but nothing useful to mapping.  

 
2017-09-24_20-07-44.png

Clicking a facility box yields no mapping fields or data either.  I tried expanding and collapsing all of the regions but no dice.

 
2017-09-24_20-09-32.png

 A quick check of the Webdrawer installation manual and the HPE support site turns up no hits for various relevant keywords. So I visited the ServiceAPI's Property and Field Definition page and see that "RecordGpsLocation" is the property to include in route details.  I add it to both the routes for the search results (WDRecordList) and record details (WDRecordDetails) templates.

 
Note that this is the webdrawer configuration file of a remote server

Note that this is the webdrawer configuration file of a remote server

Modifying the configuration file should result in an automatic reload of the IIS application.  A refresh of my search results page gives me the result shown.

 
2017-09-24_20-27-56.png

A refresh of my record details page does not result in seeing the property.  That's because I added it to the route (which funnels the data in the template), but I did not include it in any of the custom property sets used to group items into the accordion views.  Adding the property to the custom record identification property set should solve the issue.

 
2017-09-24_20-30-00.png

Refreshing the page gave me a quick laugh.  I wish the GPS location was a hyperlink!

 
2017-09-24_20-33-03.png

I'm sure there's a better way to handle this, but I found it easiest to go into the propertyRow partial template and wrap the property value output in a condition.  If the value starts with "https://www.google.com/maps" then replace the output with a valid link.  Otherwise use the normal condition.  Definitely not an ideal solution.

 
2017-09-24_20-43-04.png

Now a reload of the page gives me a usable link.  

 
2017-09-24_20-49-41.png

What's missing?

I have no way, out-of-the-box, to mark search results within the extent of one map.  So re-creating my goal is not possible without more code.  That's ok though.  I've got this! :)

Designing a CM Dataset

in ,

This post continues my Mental Health Awareness Week project. Refer to the original post for background information about the goal of this project.

It's time to configure my empty dataset!  This means using the CM features to structure my data in a way that makes it easy to find records for a mental health facility.  To me that means I must decide: do I create boxes or not?  To decide this I must analyze my data, the records, and CM features/behavior.

My sources of data include:

  1. A list of provider facilities (in excel)
  2. Florida Department of Children and Family regulatory records
  3. Images, forms, and documents from facility websites
  4. News articles culled from Google News

Since the ultimate goal is to relate the records to the facilities, we need to store the facility meta-data somewhere.  The meta-data includes: ID number, name, address, owner, and website.  Where do I store that?  The design of CM gives me three immediate, obvious options: a location, a classification, or a record type.  I've listed them in that order because that's the progressive order of building blocks within CM.  

  • A location defines a historical person, place, or thing.  There are pre-defined properties on a location for a name, address, ID number, and website.  When a record is created the location can be attached.  Users can then find all records by searching for the usage of the location.
  • A classification is akin to the dewey decimal system: a hierarchical taxonomy used to organize information.  There are pre-defined properties for the owning location, retention schedule, and security; all of which are copied to any new record associated with a record.  If each facility is created as a classification, then users can find all records by searching within the classification.
  • A record type is the definition of a type of record (go figure!).  They can be configured to use specific locations, classifications, meta-data fields, numbering patterns, and security.  They also have various behavioral settings/options, which dictate how the system reacts in certain situations.  If each facility had it's own record type, users can find all records by searching for the specific record type.

Thinking about the features as described above makes a few things obvious to me:

  1. Locations should be used to store the name of the facility owners, the governmental bodies & agencies (federal, state, and local), and nominated users of this system.
  2. Classifications should be used to organize the types of information I'll be gathering (regulatory, facility, publications, and reference material records).
  3. Record Types should be used to structure relationships between the given records.

As the title of this post indicates, I need to focus in on that last thought: structure.  I could easily store the facility ID on each individual record; and, as a result, have a flat structure with no nesting or containment.  The record's meta-data registration form could require the entry of the facility ID, as shown below.

2017-09-14_11-44-55.png

This approach limits my ability to relate the document to a second facility though.  So this approach just wouldn't work for this situation.  Instead, I'd swap out the Facility Id field for the Container field and then add the facility ID onto the container, as shown below. I can use the alternative containment relationship (not shown here) to relate a document to multiple facilities.  

2017-09-14_11-44-55.png

I've established that each facility should have at least one facility container.  Is that enough though?  How do I distinguish between regulatory records and facility records? Classifications and record types are my two options here.  If I create a few classifications (known as Categories in the US Commons lexicon), then I can require each document attach a predefined classification.  An example of this approach is shown below.

2017-09-14_11-44-55.png

With this approach I, as the user, must pick this for each document.  That's a lot of extra work at the document level.  And as the above screenshot shows, there are going to be many different types of regulatory records.  If I don't want to have to pick it per document then I need to move that information (the classification) somewhere else.  If I move the field up in the structure that would mean adding the classification to the folder.  

2017-09-14_11-44-55.png

So now, during document import, I would find the facility container matching the type (classification) of the record.  Using the above screenshot I can see that I'd need at least three containers for each facility: regulatory, facility, and news records.  The common thing between them would be the facility Id.  Clicking on a point on the map should result in a search for all the matching containers, each containing 0+ documents.  

If I stop here and don't progress further with the design I would have a viable solution.  However, it requires me to always search in order to find all records for a given facility.  No Bueno!  I really would like to be able to find a facility and browse within it.  That means doing to the container the same thing I did to the document: move the facility Id up one level.

2017-09-14_11-44-55.png

Voila!  Each facility will be created as a box, which will contain folders.  Those folders will then contain documents.  This is the most common design approach within CM.  As the solution progresses it may be necessary to tweak the design... but for now I can move on!

IDOL Firewall Rules

in

The HPE technical support folks released a new support tip regarding firewall rules for IDOL.  I like the way they've written it up and how they've explained it.  Though what they left out was how to go about actually implementing the firewall rules.  

I took the information they provided and placed it within a powershell script.  Obviously others may need to tweak it to suit their environment, but it should help most sites accomplish the task without much effort.  Just run the script via an elevated powershell command prompt (or remotely via CIM).

 

$rule = Get-NetFirewallRule -Name "HPE_CM_IDOL_SERVER"
if ( $rule -eq $null ) 
{
    New-NetFirewallRule -Name HPE_CM_IDOL_SERVER -DisplayName "HPE Content Manager IDOL Server" -Description "Enables ports 9000-9002,9070" -Protocol TCP -LocalPort 9000-9002,9070 -RemotePort 9000-9002,9070
    Write-Host "IDOL Server rule created"
} else {
    Write-Host "IDOL Server rule already exists"
}
 
$rule = Get-NetFirewallRule -Name "HPE_CM_IDOL_CONTENT1"
if ( $rule -eq $null ) 
{
    New-NetFirewallRule -Name HPE_CM_IDOL_CONTENT1 -DisplayName "HPE Content Manager IDOL Content 1" -Description "Enables ports 9100-9102" -Protocol TCP -LocalPort 9100-9102 -RemotePort 9100-9102
    Write-Host "IDOL Content 1 rule created"
} else {
    Write-Host "IDOL Content 1 rule already exists"
}