HTML reports and Sharepoint

Started by bebran, April 21, 2017, 15:30:54 PM

Previous topic - Next topic



We use Sharepoint for storing documentation, but it seems to be quite a challenge to make the HTML reports work, if the report is stored and accessed via Sharepoint. The PDF reports work fine, but doesn't have the same interactivity.
Has anyone succeeded in storing & accessing the HTML reports from Sharepoint, and if so, how is it done?

Best regards

Phil Beauvoir

Hi, could you explain exactly what problems you're experiencing by using Sharepoint?

If you value and use Archi please consider making a donation!

Jean-Baptiste Sarrodie


I don't know sharepoint enough (I don't use it) but I'm not sure it can easily use "raw" HTML content by itself. You might have to publish the report on another webserver (apache, IIS...) and create a sharepoint page containing a Page Viewer Web Part.


If you value and use Archi please consider making a donation!


Seems like our Sharepoint security settings prevents HTML files from being displayed directly in the Page Viewer Web Part and instead asks the user to download the file(s) and run them from the local download location. The 'problem' is discussed here:
Changing the security settings is not an option. Changing all .html extensions to .aspx seems like a viable option (haven't tried it), but will need post processing of the report files before uploading to Sharepoint.



I'd like to bump this and echo the original posters question

I like the interactive html reports that ArchiMate produces and I'd really like to replicate this in our architecture and projects sharepoint site.
Is there an easy way of doing this?

Or is the simplest way to just publish to a shared network drive and link ?
This would work while at work, however would not be cloud accessible.

Hoping there might be a simple answer to this now as I've spent a lot of time putting the model and reports together.

edit: This -->
might help, is there a deployment timeframe for this?


I think the other problem you'll find is the ability to run javascript in situ.

Other than a shared drive (gah!), the best way, as mentioned, is to get an Apache (or similar) web server set up (you can control access by named users too). I guess the real challenge is cheaply standing one up in your organisation so it's private. I've been known to use a Raspberry Pi for this.

You could automate the generation using the Archi command line to run the report, plus a script to copy the files up to the web server.

As there are a LOT of files to publish, I find having a staging area on the web server is best, then do a 'move/rename' of the folders to bring the new ones quickly online.

When you do have the files somewhere, I have found that different browsers behave very differently (e.g. drill down, accuracy, speed). I usually use Safari, but often resort to Chrome or Firefox.

hope that helps?


Sharepoint is not intended, AFAIK, to store HTML interactive documentation. Maybe there is a way to make a sharepoint page, to be exposing external content published on external web-server.
If you want to make it through sharepoint ofc.


I have the same issue with interactive pages but with Atlassian Confluence, so I have a little web server for my Archi HTML reports and I embed the PNGs into Confluence :-[


I think I have a solution if you're still interested.  8)
I have been trying to find a way around this problem for the past day.
Initially I thought it would be simple, after all you can sync SharePoint with your local drive so all that problem with not being able to embed a website in SharePoint goes away because you open the synced copy from your own drive.
Only that doesn't work and I couldn't figure out why, all the files were visible, everything was in the right place, you could go into the subdirectories of the report and open all the files so they were there.

Then I noticed it (and I wish I could remember exactly how) a portion of the path was not what it seemed.

For example the path looked like it was a normal path to the local copy "C:/<<myUserPath>>/<<Company OneDrive>>/<<SharePoint site>>/<<Path in SharePoint>>" - that is what was displayed almost everywhere I looked.

But the actual path in SharePoint had some unusual features when I saw it pop up in one place.
the SharePoint site in the URL was "/BS-SS-Data and Insight - Documents/" but it had popped up as "/BSS-SS~1/", and the same type of abbreviation for almost all of the SharePoint path folders where there were long folder names.
Then it struck me that on some level it was failing because somewhere under the bonnet the SharePoint sync was applying the old DOS 8 character limitation on directory names.

Edge developer tools was showing that the JavaScript and CSS files were not loading as it could not find them.

At first I tried writing a script to load all the scripts with a "corrected" path, which was taking me ages and prone to error.

This morning I had a much simpler idea, rewrite the pathname as the page loads.
After a bit of experimentation I found I only needed to change the SharePoint site name portion of the path so I added the following code to the top of the <head> tag in index.html.

      var searchStr="/BS-SS-Data%20and%20Insight%20-%20Documents/";
      var replaceStr="/BS-SS-~1/";


Now it works perfectly (well for me) hope this helps.