BookmarkSubscribeRSS Feed

Storing web pages on GitHub for consumption inside the SAS Visual Analytics Data-Driven Content

Started ‎11-09-2023 by
Modified ‎11-09-2023 by
Views 351

You have options when it comes to deploying custom web applications which you want to be consumed inside a Data-Driven Content object in SAS Visual Analytics. Depending on the requirements, you can decide to deploy the web application:



Find more articles from SAS Global Enablement and Learning here.


As you may know from reading my articles, developing web applications to enhance SAS Visual Analytics functionalities is a robust capability. With some knowledge about web programming (HTML, JavaScript, CSS), you can create web pages which can be embedded inside SAS Visual Analytics and interact with other objects. This integration functionality has been available since the early version of SAS Viya in the form of the Data-Driven Content object.In SAS Viya 3.5, it was possible to deploy the web applications on the web server included in the SAS Viya deployment. In later releases of Viya deployed using Kubernetes, this process is a bit more complex. As mentioned in the introduction, you can deploy the web pages on a specific container and include the container in your Viya deployment as I described in this . You have also the option to deploy the application in a pre-built container designed for that specific purpose using the Data-Driven Content Server. You can also host the files in an existing web server in your infrastructure and adapt the security configuration of SAS Viya to allow access from that external server.When discussing with consultants and customers, it appears that deploying a specific container in SAS Viya environment is more challenging than it was in SAS Viya 3.5. The main reason is: security. While the risk of deploying a few HTML, JavaScript and CSS files into an existing web server is minimal, building and deploying a container requires more caution and security checks. Of course, even when deploying the web pages inside a web server, you should make sure there is no security holes into your application, but deploying a container requires:


  • Validation of the original container
  • Security checks on the web application itself
  • Enforcement of security rules in the deployment process


These tests can be automated, but they require more time and efforts.


This is where using GItHub pages can be handy!


What are GitHub Pages?


The marketing message on is clear:



Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.




You can host your web projects directly in a GitHub repository and deploy it automatically when you push your changes. Here is the development and deployment process flow.


  1. Create a GitHub repository
  2. Clone the repository
  3. Write the code of your application
  4. Commit the changes to your code
  5. Push the code to the GitHub repository
  6. Check the resulting web application


As you see in these steps, there is no mention about deploying the application nor build a container and deploy it. This is the “magic” about using GitHub Pages. GitHub handles the deployment for you behind the scenes. This means, as a developer, that you can focus on your application and forget about the deployment as it is automated.



By default, the repositories published on GitHub Pages are public.  If you have a GitHub Enterprise account this can be changed and the published repositories will be private by default, but this configuration can be changed to allow public access.


How do you deploy your application on GitHub Pages?


As mentioned in the previous section, you can create a repository, write your code, commit changes and push your code to GitHub like you do for any project hosted on GitHub.


The only difference will be that your repository should include a special file explaining how to build the application and where the static content should be copied.


To do this, create a folder named .github/workflows in your repository. This is the default location for the GitHub Actions.


In the folder, you can create a file with .yml extension and give it the name you want for example: deploy_pages.yml


When done, write the following code in the deploy_pages.yml file:





This YAML file may seem a bit complex at first sight, but it describes all the steps needed to build the application. In this case, the application is based on Vite JavaScript framework. This means that the application relies on npm to install the dependencies and build the dist folder which contains the static content to be rendered for the application.


The process to create the file and the configuration needed in your application are for example described on the Vite website. I copied the file from the website and adapted the name of the branch to indicate that the master has to be used to monitor changes and trigger the workflow.


While writing the application for this article, I had also to add a base variable in the vite.config.js file:





This change was required because the application is accessible from: Defining the base path helps Vite to configure the URLs properly when building the application.


If you are using other frameworks or other tools to build your application, stay cool as there is plenty of tutorials on the web to help you deploy your application under GitHub Pages.


The last step I had to perform was to tell GitHub that the workflow should be executed when a push action happens on the repository.





If you need more information about GitHub Actions, you can find more details on the GitHub website.


Configuring SAS Viya


So far, we have been talking about the deployment of the application inside GitHub Pages. There is also a specific configuration needed within SAS Viya. This configuration is for the Cross Origin Resource Sharing (CORS). By default, SAS Viya is configured to allow access only from pages which are hosted on the same domain. If CORS is not configured properly, the web browser will not be allowed to send data from the Data-Driven Content object to as it would be considered as a security risk. To allow these communications to happen, you should configure the definition as indicated in the following article:



On my environment, I configured the property like this:




This means that any web page which is hosted on will be accessible from SAS Viya and can be used inside a Data-Driven Content object.



What about security?


When deploying your application on GitHub Pages, by default, this application will be accessible by anybody knowing the URL. At first sight, you might be worried about security. Of course, you should not store sensitive data in your HTML or JavaScript, but this is a good practice for any web page (not specific to applications accessing SAS hosted data).


In our case, the applications is designed to be used inside the Data-Driven Content object. This means there is no need to store credentials in the application, as it will rely on the authentication mechanism provided by SAS Viya. Running the application outside of SAS Visual Analytics makes no sense. If the application is not embedded in SAS Visual Analytics, the application will not receive data from SAS. The data which is used in a Data-Driven Content object is passed by SAS Visual Analytics to the object which means if you are not allowed to see the data in SAS Visual Analytics, these data will not be available to you inside the web page.


The same applies for other SAS Viya components. If your application accesses the CAS server through REST APIs or calls SAS Job Execution to execute SAS Viya Jobs, your web application will have to handle authentication if it is used outside of SAS Visual Analytics. Without authentication, accessing CAS data or executing jobs will not be allowed (unless you configured Guest authentication and anybody would be allowed to execute a job for example).




When it comes to deploying your web application to be consumed inside a Data-Driven Content object within SAS Visual Analytics, you have many options. Most probably the simplest approach is to rely on GitHub Pages to host the files, but most importantly to hide the deployment process from the developers. Using CI/CD process eases the delivery of the application modifications.


Of course, this option requires some configuration inside SAS Viya, but it gives the opportunity to quickly test and prototype web applications. The downside of this is that you are relying on GitHub Pages availability. When deploying your final version of the application you may have to rethink your deployment process to may be include the application in its own container and deploy that container to production.


If you want more information about this deployment topic, you can refer to these articles:



The code for this blog containing a simple application can be found on GitHub.


Find more articles from SAS Global Enablement and Learning here.

Version history
Last update:
‎11-09-2023 06:04 AM
Updated by:



Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.

If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website. 

Register now!

Free course: Data Literacy Essentials

Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning  and boost your career prospects.

Get Started