Please note, that the reasons for instigating this major system change, and the processes involved (political & technical), are not covered in this blog post.
Anyone who has ever had responsibility for changing a central IT system, will know that it’s never a pain free experience, and can be fraught with frustration. Thankfully, in our particular instance, I can report that the majority of bespoke functionality and add-ons, were successfully ‘ported’ over from one system to another. Data migration, for the most part, was also a success.
Once iSAMS was in place, there were some data report requirements; iSAMS uses SSRS for it’s reporting engine, so several reports had to be re-created within this environment.
One such requirement was for a health & emergency contact report, which in short, was to include the student photograph and an array of medical and parental contact information; ideal for trips etc.
It goes without saying that this report also needed to be clearly stamped with instructions and guidance pertaining to Data Protection legislation.
The report itself was a fairly complex composition of embedded reports and queries, which resulted in a nice presentation of the required data.
Whilst the report performed the task perfectly, from a data extraction perspective, and was indeed ‘stamped’ (in bright red) with instructions regarding the shredding of the document after use etc, there were no details about who had actually printed the report.
After a lot of Googling and code testing (including the creation of bespoke SSRS functions within the report), I came to the conclusion that grabbing the name of the user who actually instigated the report, was not possible from the server.
Logically the workflow doesn’t allow for this, as from an SSRS perspective, the ‘user’ and indeed the ‘machine’ firing the report, are of course, the iSAMS generic user and iSAMS server!
A re-think of the workflow, led me to establishing the presence of an iSAMS ‘cookie’ (using the excellent fiddler program to sniff traffic), providing username details. All I needed to do, was extract this cookie and send it as a form parameter, when the report was requested. This parameter could then be included within the SSRS report, as an SSRS Parameter field, and displayed accordingly – simple!
A Real World Solution or Just a Proof Of Concept?
Of course, I fully appreciate that it only needs iSAMS to overwrite this page on an update, and my code snippet will vanish.
To cater for this potential code destruction, we have implemented the below PowerShell script, which runs on a nightly schedule. The script automatically emails the ICT Department, if there are any changes made to this particular file (using the Compare-Object PowerShell cmdlet).
It’s a useful PowerShell script in it’s own right!
Clearly an even better solution, would be having this functionality officially built into the iSAMS product, thus allowing for the creation of traceable reports. However, in the meantime, whether you choose to view this as just a ‘proof of concept’ or a ‘real world solution’, it certainly seems to work for us.
It transpires that the framework files do indeed get overwritten on a nightly basis .
I believe this is performed by ISAMS referencing a ‘Framework.xml file’ (in the root), which stores file information, including file hashes.
Using onlinemd5.com I created a hash of the ‘new’ file, and updated ‘Framework.xml’ accordingly. The question is whether this ‘Framework.xml’ file is centrally updated by iSAMS, periodically? I suppose only time will tell.
It could be that only iSAMS can truly prevent the file from being overwritten – thus, a support email has been sent, asking for guidance.
In the meantime, we will run with this process; of course, if anyone else has a better solution, please suggest!