HTML reports and Sharepoint

Started by bebran, April 21, 2017, 16: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!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.


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.


Quote from: ChampagnePerry on June 17, 2022, 12:07:12 PMAt 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.

This seems very close to what I see but I can't find the path and what they should be. Can you provide any more details/examples?





A colleague of mine had found a workaround : rename all htmls files to aspx and change all links accordingly from .html to .aspx (you can user Notepad++ to replace in multiple files), then upload everything to a Sharepoint Library.
We have an old Sharepoint version (2013), I do not know if it works on newer ones.



accidentally posted twice


I've just set up a more robust solution (though it may not be better).
The local path allocated by SharePoint can vary quite a bit depending on how individuals are set up. but seem to follow a similar format.
mine was
C:\Users\p...m\Barnardo's\BS-SS-Data and Insight - Documents\Products\....\Information Journeys\ (masked to protect the innocent ... and me)
<Drive>:<user path>\<oneDrive>\<Base SharePoint Folder>\<SharePoint Folder Path>
A colleagues was similar but the base SharePoint Folder was named differently their base SharePoint path was
\BS-SS-Data and Insight - Data Engineering, Products and Analytics\

First create a new html file and a small image in the same directory (I've called mine home.html and test.png)
The home.html has an image tag an I use this to find the path.

Second tell people to sync the SharePoint site to their local machine.

Third make sure they go to the directory on their machine and choose the option to "always keep on this device" (should be a right mouse click on the directory in file explorer)

It will take a little while to sync...
The home.html is a simple page that has a little code that simply replaces the image src with an abbreviated form of the current path, it loops through possible abbreviations until it finds one that works.

It does this because I know (or guess) it is only the first part of the file path that differs between devices (the results we were seeing was <user Path>/<OneDrive/BS-SS-~1/ on my machine and <user Path>/<OneDrive/BS-SS-~2/ on some others) but the rest, if they are abbreviated, will be appended with ~1.

Because this is a separate file you can republish to the directory without worrying about it being overwritten and everybody who has a synced drive will get refreshed.

Here is the home.html code (sorry if it's a bit ropey it was a quick fix but it seems to work).

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">
<html class="model" lang="en">
 <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
 <h1>Trying to redirect you to the model...</h1>
 <p>SharePoint does something strange with the file path so I am trying to find the correct path for you.</p>

 <h1 id="strTest">Testing redirection with</h1>
 <p id="t1">1</p>
 <img id="test"/>
 <p id="TestPath"></p>

 var correctedPath=tempPath.replace("home.html","index.html");

 function getPos(str, subStr, i) {
 return str.split(subStr, i).join(subStr).length;

 function correctPath(mPath , baseDir) {
 // correct path has an optional second parameter that has the "base" directory
 // the base directory is the first directory inside the local synced copy of SharePoint Library
 // replace the encoded spaces with real spaces
 mPath=mPath.split("%20").join(" ");
 baseDir = baseDir || "";
 keepUntil = -1;
 if (baseDir.length>0) {
 for (i=0 ; i< splitPath.length-1;i++) {
 // if the path section may need abbreviation check the length and abbreviate if needed
 // this assumes that all abbreviations are appended with ~1 this may not always the case
 if (i > keepUntil && i < splitPath.length-2) {
 if (splitPath[i].length>8) {
    // DOS paths weren't allowed spaces so strip out any and append with ~1
 splitPath[i]=splitPath[i].split(" ").join("").substr(0,6).toUpperCase()+"~1";
 // the first abbreviated path is the most likely to have an alternative suffix
 newPath = splitPath.join("/").replace("~1","~#");
 return newPath;

function findPath(restart = false) {
 // finding the path is done with a timeout, this gives time for the image to load so we can check if it has been found
 // the intervalTime may be changed but it can look a bit uncontrolled if set too fast
 // currently only checks ~1 - ~9
 testImg= document.getElementById("test");
 if (document.getElementById("t1").innerHTML>9 ) {
 document.getElementById("strTest").innerHTML="Sorry could not find a path that worked";
 } else {
 if (testImg.naturalWidth>0) {
 document.getElementById("strTest").innerHTML="Success: we have found a path preparing to redirect you";
 } else {
 } else {
function Go(){


I knew it was abbreviating the path because I saw on my machine when the path got really long my file explorer was sometimes showing this abbreviated path briefly when I went to cut and paste the path.

I recognised it as an ancient DOS path right away, when DOS first got long file names it still used these abbreviated paths in the background.

This seems to work for everyone here at the moment.


Just realised I didn't really explain how to find the path.
Say your local path is something like:
C:\Users\myUserName\CompanyOneDrive\Sharepointsite folder\subfolder\subfolder etc


C:\Users\paulm\Barnardo's\BS-SS-Data and Insight - Documents\Products\Property Dashboard\Supporting Documentation\HTML Model\index.html

In file explorer I just tried typing in
C:\Users\paulm\Barnardo's\BS-SS~1\Products\Property Dashboard\Supporting Documentation\HTML Model\index.html
C:\Users\paulm\Barnardo's\BS-SS~2\Products\Property Dashboard\Supporting Documentation\HTML Model\index.html
etc. until I found one that worked.
You can do the same in all the directory entries but my code assumes that once you get further down the directory structure duplicates are less likely, it is also possible that once you get beyond the initial abbreviation it's not a problem.
NOTE windows itself will cope with the long path so you can test it a step at a time if you want to get to the full abbreviation. i.e. once you have found BS-SS-~2 works go for the next folder name that exceeds 8 characters and try \BS-SS-~2\Products\PROPER~1 (~2, ~3 etc) that way you can step through each folder and find the path.
If you wanted to make it work for all instances then you probably have to count how deeply index.html is nested in the directory structure and include a test image file at each level then iterate through the folders until you had reached the correct level of nesting.

Let me know if you need more info.



I have figured out, how you can publish to Sharepoint.
1. Export HTML report to folder
2. Rename all html files extension from EAPK.., element and hints to aspx extension. I use PowerToys to do that.
3. Replace all occurancies .html to .aspx in index.aspx . and folder EAPK... I use Notepad++ to do that.
4. Enable custom pages on Sharepoint site. Set-SPOsite -DenyAddAndCustomizePages 0 (
5. Upload folder to Sharepoint.
6. Go to url of index.aspx. You can now view model in Sharepoint online