Friday, 21 October 2016

Building SAS Apps Locally

I've recently been using Visual Studio to build my SAS Web Apps, which is great as the intellisense will even scan css files to help with code completion.  Perhaps the best feature though is the ability to right click and immediately 'view in browser' - which spins up a local web server and avoids the need to constantly modify files on the main dev SAS web server.

However - there are a few things to remember when using this feature to actually connect to SAS.

Same Origin Policy

In simple terms, this is a browser security feature that prevents javascript from connecting to a different server than that from which the page was served.  You'll know you're affected if you see something like this in the console:

XMLHttpRequest cannot load http://SASMIDTIER:8080/SASStoredProcess/do. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:54048' is therefore not allowed access.
To avoid this (using chrome) simply launch from the command line with that feature disabled - as follows:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --user-data-dir="C:/Chrome dev session" --disable-web-security


Now that we are launching from a local host, the Boemska SAS adapter is unable to automatically determine the mid-tier location.  This info needs to be provided, but not hard coded as we still need the code to work in different environments when it gets promoted.  The following javascript code serves:

  if (location.hostname === 'localhost' || location.hostname === '') {
    var strHostURL = 'http://SASMIDTIER:8080/';
  } else {
    strHostURL = null;

  var adapter = new h54s({ hostUrl: strHostURL });

HTML file location

This may not be an issue with your web server / configuration, but something to remember.  I normally keep my my web files organised as follows:
  • ROOT.war
    • JS
    • CSS
    • HTML
    • Images
In order to reference scripts / css / images from my html files, I normally use the ".." syntax to tell the browser to look 'up and then down' a directory, eg as follows:

  <script src=../js/h54s.js></script>

Unfortunately that approach doesn't work in the web server spun up by VS2015, so I have to temporarily move my html file up into the parent folder and permanently change my references to read as follows:

  <script src=/js/h54s.js></script>

For more information on building Web Apps with SAS you can also check out this guide.  Enjoy!

Wednesday, 5 October 2016

The native implementation module for the security package could not be found in the path.

Noticed today that our UAT 9.3 environment was failing to execute the SAS ExportPackage utility, with the following error returned:
The export process has failed.  The native implementation module for the security package could not be found in the path.
I'd come across this issue before, and this was (effectively) the same piece of code.  So what gives?  I launched a shell session locally, using the system account (sassrvuat), and reran the command.

It worked.

Hmm..  Must be an issue with the UAT machine (most likely since our 9.3 upgrade as it worked on 9.2).  I logged into sasapp with sassrvuat and tried to open DI Studio using IWA.  I get an interesting popup:
C:\Program Files\SASHome\SASDataIntegrationStudio\4.3\sspiauth.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform The native implementation module for the security package could not be found in the path.
Seems my old colleague Stig was onto something with regard to the sspiauth.dll file and 32 vs 64 bit compatibility.  Checking out the folder below, we can see several versions:
Comparing the file sizes it was clear that we had 32 bit DLLs (112kb) instead of 64 (107kb).  The solution therefore was simply to copy sspiauth.dll from:
  • C:\Program Files\SASHome\SASFoundation\9.3\core\sasext
To the following locations:
  • C:\Program Files\SASHome\SASDataIntegrationStudio\4.3
  • C:\Program Files\SASHome\SASPlatformObjectFramework\9.3