5 Tips for SAS App Developers

If you have SAS, you have a powerful platform for Enterprise App Development - one that runs extremely fast, connects to any data source, and ticks all the boxes required by IT. Not only that, you likely have a team of SAS Programmers in your department with the ability (and requisite access) to rapidly build routines to extract that data.

These two facts alone make SAS the best platform for building operational enterprise applications. To re-iterate - what other platform enables Business SMEs to write secured, data centric web services? Your SAS developers likely know both your data and the business processes well enough to build the backend for your point solutions at breakneck speed. All components needed to operationalise the app (web server, load balancing, authorisation / authentication, data layer, encrypted communication) are bundled and preconfigured in your existing SAS environment. Throw a frontend developer into the mix, and - prepare for takeoff!

I know - pretty exciting right? The possibilities for SAS Apps are endless. User-friendly interfaces for complex actuarial models. Lightning fast analytics on Viya with CAS. Bespoke applications that can be scaled to thousands of users with zero deployment footprint.

Like anything though, there are good ways and less good ways to build apps on SAS. Follow these 5 tips and be on your way to building your own HTML5 SAS Apps.

1 - Separate your Frontend and Backend

Seriously. This is important. Do not - under any circumstances - stream HTML from your SAS programs! Apart from the fact that nobody (not even you) will be able to understand your code, it is a fundamentally inefficient approach. Your front end should be on your web server, and your backend (SAS code) should deal only with data. Why? 

It’s faster to run.

The SAS Web Server is optimised for serving files and HTML / CSS / Javascript content. Requests for static content take one ‘hop’ (no metadata authentication needed, or session to spawn) and so your app will launch instantly - giving your user an interface whilst waiting for backend requests to complete.

It’s faster to build.

If your app does anything more than ‘proc print’ (ie, it has a user interface) then you will need to use Javascript to handle the application logic. However - building your app with just HTML and Javascript is like building a house with your bare hands. Possible, but takes a lot of time, and the end result will suffer! Instead - make use of the plethora of tools and frameworks available to accelerate and secure the development process - such as Angular, React.js, JQuery, HandsOnTable, D3, Bootstrap, etc etc.

It’s easier to maintain.

Got a problem in SAS? It’ll be easy to spot through an analysis of the log and examination of the outputs. Got a problem in your frontend app? If it can’t be fixed through examination of the console and network requests, you might try breakpoints and console.log() statements in Javascript. This is easy to do if you can run your app locally (localhost). If your frontend application logic is split across multiple Stored Process via a complicated series of conditionals and put statements - good luck.

2 - Standardise your interface

A SAS Application will almost certainly have some background (AJAX) calls to the SAS backend. And if there is no standard, then every SAS developer will call SAS in a slightly different way. Having a ‘default’ way to call SAS will reduce time spent on design decisions, improve maintainability, increase reliability, and provide a ‘touch point’ for inspections.

Whilst you can go ahead and use trial and error to figure out the best ways to handle numeric precision, special characters, huge data volumes, and developer documentation - there is an alternative. The open source SASjs Adapter is available on GitHub and provides exactly this. It’s extensively tested, well documented, fast and secure - check it out: https://github.com/macropeople/sasjs

3 - Document your Services

Now you have a standardised interface, your SAS programs (Stored Processes) can be thought of as backend Services - all of which will have inputs and / or outputs. These endpoints should be documented for the benefit of frontend developers and / or testers.

By working with such documentation, it becomes possible to disconnect the dependency between frontend and backend developers. Stuck due to some issue (eg missing data) on the SAS side? No problem - create a ‘stub service’ with correctly formatted sample outputs and work can continue on the web side.

4 - Role Based Security

When designing your app, consider your users. Will everyone need the same permissions? Or will some functionality be restricted to say, admins? By grouping SAS Services into folders and applying metadata permissions at that level, access to application functionality (and the app itself) can be easily segregated and restricted. 

5 - Increase Multibridge Connections (SAS 9)

SAS is deployed with 3 multibridge connections by default. This means a maximum of 3 concurrent calls can be made to your app (or any app on that server context). If you have more than a handful of active users - you will need to increase this!

A rule of thumb is to have 3-5 multibridge connections per CPU core, but this really depends on the number of users you have / number of requests they will make / how long those requests take to run.

Bonus Tips

If you’re as serious as we are about building awesome web apps on SAS, then do get in touch. App Development on the SAS Platform is what we do all day, every day! We'd love to tell you more about how the open source SASjs framework can help you rapidly deliver great-looking, fast, supportable HTML5 apps on both SAS 9 and Viya.

Other offerings include:

• AF/SCL Modernisation - migrate your legacy desktop app whilst retaining critical business logic
•  Data Controller - enables real time data uploads with approval workflow and audit trail
• QuickStart - a fixed price proof of concept to get your project up and running
•  Training - getting you up to speed on app development with SAS

In the meantime - here are some more resources for building web apps on SAS:

• SASjs educational website - https://sasjs.io
• Quick Guide to building web apps on SAS: https://www.rawsas.com/2015/12/building-web-apps-with-sas/ 
• Detailed Guide to building web apps on SAS: https://www.sas.com/content/dam/SAS/support/en/sas-global-forum-proceedings/2020/4260-2020.pdf
• SAS communities article
• Test your knowledge of building web apps with SAS: https://sasensei.com/questions/filter?tags_any=[13]