03-04-2016 03:24 PM
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap.min.css"> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.0/jquery.min.js"></script> <script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js"></script>
This works great and I instantly get access to these tools.
However, I would like to download these resources (and others) so that I can load them locally. But I have no idea how to point them to the correct path.
For instance, if I attemp to load bootstrap where it is located on the web server like this...
<link href="/sasdata/Projects/myproject/libraries/bootstrap.min.css" rel="stylesheet">
I get the following error in
Failed to load resource: https://myserver:port/sasdata/Projects/myproject/libraries/bootstrap.min.css
Failed to load the server responded with a status of 404 (Not Found)
So, how do I load the resource properly from the sever? I tried to put it in the metadata folder but can't seem to copy and paste any files in there.
03-07-2016 07:41 AM
03-04-2016 03:46 PM
between the quote after href= and your file location. (I can't put in the full line because this site trips up on the html.)
I believe this is the correct way to reference a local file.
03-04-2016 06:52 PM
Using file:// would result in your browser attempting to locate a file on the local computer, not the server. These could be the same but that would be a coincidence and is prone to errors.
Bring the files within the server's reach by placing them under the htdocs location or referring to their location using eg. <directory> or <location> tags in the httpd config. This is fundamental security to avoid browsers loading arbitrary files from your server. Also the files should be readable by the user the webserver process runs as (commonly apache or nobody).
03-07-2016 07:41 AM
03-07-2016 03:27 PM
This appears to be correct, though my folder structure appears to be a bit different (using SAS 9.4). I don't have permissions to access any of these directories so I'll have to get in contact with admins to make this happen. Thanks for the help.
03-09-2016 06:25 PM
I sat down with an admin and went to the midtier server and thanks to the path you gave it was easy to find the scripts, images and styles directories inside sas/sasconfig/Lev1/Web/WebAppServer/SASServer1_1/sas_webapps/sas.storedprocess.war/.
Do you have a reference of where you found out how to do this?
I can't seem to find any documentation on this extremely useful feature.
03-10-2016 09:37 AM
That's great! I don't think I ever found this in any SAS documentation, though it may be there somewhere. It's probably not there because it's a bit non-standard. I think I was trying to figure it out myself one time and stumbled upon it.
Make sure to note this, though: Whenever the web applications are updated (like through hotfixes or a maintenance release) it will move your current *.war directory for the application into a Backup directory that it creates. So after an upgrade you would have to move the custom files from the Backup directory back into the main scripts/images/styles directory.
03-10-2016 09:50 AM
Wow. How the hell is there no documentation on this? We are planning on doing a few custom web apps through SAS stored processes. I suppose nobody does this sort of thing? We are finding SAS VA to be quite limited in its ability to do non-filtering (ajax-ish stuff) operations which is leading to these custom web apps which could lead to python + D3 as the permenant solution.
And thanks for the tip to be wary of updates in the future.
03-22-2016 06:24 PM - edited 03-22-2016 06:28 PM
As Juan points out, if you've got 9.4 then it's far easier to just use the htdocs folder under Lev1/Web/WebServer/htdocs than to inject static files into the exploded war files. Any directories you create in htdocs here will be surfaced as <server>:7980/<directory>, and you can link to those static files without hardcoding the server name by just using the leading slash, i.e. src="/<directory>/myfile.js".
Hope that helps.
03-23-2016 10:12 AM
Thanks Nik for the excellent post. I had no idea what Juan was posting and will probably need to sit down with an admin to understand these configuration things. I have developed non-trivial web applications (oustside of SAS) before just don't understand all this apache/linuxy ninja stuff going on in the background.
Your extension looks very cool, just that there is no way we would plug-in some random guy's github into our application to make things a bit easier. Can you clarify what the 'standard' way is for large corporations to build web applications that rely on sas computation in the back end? Is everyone using your product or is everyone writing put statements in stored processes?
03-24-2016 07:05 PM
It isn't 'some random guy's github' (it's ok, I do get exactly where you're coming from). It's a professionally developed library that we've been developing and using in production as a commercial product for a very long time. Over the last 3-4 years we've used it alongside SAS to deliver operational information systems that support upwards of 2k concurrent users, some of which our clients say bring them over $100 mil in annual benefit. We're a SAS partner, ok only 7 people, but atypically most of our guys are experienced Java and HTML5 devs. We specialise in the exact kind of application development you're talking about, hence I hang out and try to help in this subforum.
What the adapter enables you to do is separate your front end and back end logic when building your web applications, as is standard practice everywhere outside the SAS world. It lets you hire experienced HTML5 app developers to do your front end, while you take care of the back-end application logic in SAS. Have a read the documentation available on GitHub, and maybe have a look at https://github.com/Boemska/h54s-angular-seed-app as well - personally I think this explains what the adapter does much better than the h54s page. What the codebase does is facilitate AJAX communication to SAS by wrapping the native AJAX object in a very SAS-specific way, by allowing the SAS programmer and HTML5 programmer to pass tables back and forth to build asynchronous applications. It also handles redirects to the SASLogon application, debug logs, and a couple of other things. It's open-source, so you're free to inspect what the code does - there's no black magic there.
In regard to your last question - just because these kind of solutions are currently implemented in large corporations using put statements doesn't make it right. It is done this way because until now there hasn't been a better alternative. Architecturally it's a terrible way of doing things - it's extremely bad practice, not to mention that streaming static content is a very bad use of your analytical processing CPU time. There are a couple of reasons why as a community we've evolved into doing this with put statements; the first, I think, is that the problem's mostly been approached by SAS devs from a SAS-developer-centric standpoint, learning 'just enough' HTML coding without taking the time to properly learn/understand web application architecture and follow the established best practices that the rest of the world does. The other, I'd say more obvious one, is that until SAS 9.4 we haven't had our own web server / static area (htdocs) provided by apache where we could easily host our html/js/css files - the best we've had is a static.war deployed within tomcat/jboss alongside the other SAS web applications (hosting static files from a JVM is again really bad practice, which is what static.war does). This lack of access to a proper web server to host these static files on has made it very difficult to develop web applications properly, and before 9.4 people would have to beg IT to give them some webserver space; so as you'd expect, everyone ended up using put statements to output static html content.
This doesn't change the fact that this 'established' approach is extremely hacky and bad practice. We hire experienced HTML5 application developers for this exact reason, and it's their guidance that's resulted in us developing apps the way we do. I have nothing to sell to you, nothing to gain from you using the code we made available... you don't have to use it. Nevertheless I highly recommend you build your applications in this way. What I'd say is, see if your organisation has a digital/marketing team who build webapps for a living, and then try to engage with them to help you build some of these front ends. Maybe have them to look at the codebase as to help you understand what the H54S library does - there's no way you should have to shoulder the responsibility of incorporating third party code that you don't fully understand.
I can see what you're trying to achieve, and I know this post comes over a little argumentative but I'm just trying to help. We were where you are around 4 years ago. If you want to see some of the work we've delivered for our own clients feel free to ping me. I think you'll be blown away.
03-07-2016 09:33 AM
you found good answers here. In case that you work with SAS 9.4 or with a previous version with an Apache server installed:
The most easy way to enable you and the users to access an static file (as a js/css file), is to create a folder under your root folder for Apache (or SAS httpd server), and enable the access to the folder on the sas.conf, or the httpd-ssl.conf, as it seems you are working on a SSL configuration of the Web server/Apache/httpd
Some good references:
Need further help from the community? Please ask a new question.