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

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:

Inside a container in your SAS Viya environment. See the article Deploy a custom web application in the cloud for Data-Driven Content object in SAS Viya 4
Store the files and expose them in an existing web server.
Using GitHub Pages. (this article!)

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 pages.github.com 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.

Create a GitHub repository
Clone the repository
Write the code of your application
Commit the changes to your code
Push the code to the GitHub repository
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: https://xavierbizoux.github.io/git_pages. 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 https://xavierbizoux.github.io/git_pages as it would be considered as a security risk. To allow these communications to happen, you should configure the sas.commons.web.security.cors definition as indicated in the following article:

All about CORS and CSRF for developing web applications with the SAS Visual Analytics SDK

On my environment, I configured the property like this:

This means that any web page which is hosted on https://xavierbizoux.github.io:80 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).

Conclusion

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.