Deploy SAS Report Packages made easy!

1 Like

In the context of SAS Visual Analytics, there may be instances where you wish to deploy a single report and make it accessible to users via the web. To facilitate this, SAS offers the SAS Report Package. In this article, I will illustrate the process of exporting the package and deploying the report packages in a separate web container. This container can subsequently be deployed in your chosen cloud provider.

What is a SAS report package?

From the SAS documentation:

The report package is a compressed file named report-package-name.sasreportpkg.zip that includes a snapshot of the report, images, style sheets, and data that are needed for a given set of report objects. The package includes all of the data that is needed to render the selected objects, as well as the data that is required to support any actions that are defined between the objects.

How do I deploy a report package?

Unzip the content of a report package (report-package-name.sasreportpkg.zip) to a web server that hosts your web page (HTML, CSS, and JavaScript).

As evident from the text, the report package serves as an independent edition of an already existing SAS Visual Analytics report or a component of a report that can be deployed to a web server for viewing. One of its advantages lies in its scalability, allowing for the adjustment of the web server's capacity according to consumption requirements, without affecting the SAS Viya environment.

How do you generate a SAS report package?

You have two options to generate a SAS report package:

Interactively using SAS Visual Analytics
In batch using the SAS Viya CLI

Interactively using SAS Visual Analytics

The report package can be exported using the toolbar at the report level.

You can then select the elements from the report you want to export.

Notice that certain elements contain Warning messages. To access further details, simply click on the Warning.

Considering that we will be hosting the report package on our own web server, deselect the Save to SAS content option under Persistence. Once you click the Export button, a message will appear indicating that the package is being generated and the download will commence once the generation process is finished.

In batch using the SAS Viya CLI

While it is acceptable to utilize the interactive option, you might consider automating the export process to minimize user interactions. By employing the SAS Viya CLI, you have the ability to utilize the build-package plugin.

How to deploy SAS report packages?

As stated in the SAS documentation, it is recommended to unzip the report package and host the files on a web server of your choice. If you already have a running web server, simply copy the files into it to complete the process. However, if you prefer to keep the report package(s) separate from other web content, deploying the SAS report package(s) on a standalone web server and then deploying it into your preferred cloud provider may be a better option. In this case, you can store the extracted report package(s) in a specific volume and mount that volume to a web server image when deploying the container into Kubernetes.

Alternatively, you can create an image with the extracted file, store it in a repository, and deploy it from the repository into Kubernetes. This approach allows you to have more control over the build process, as well as the ability to test and validate the image. You can even automate the process using a pipeline in GitHub, GitLab, or BitBucket.

To build the package on your local machine, ensure that Docker is installed. Create a folder on your machine, which will serve as the project's home directory. Within this folder, create a file named "Dockerfile" and a folder named "reports". Extract the SAS report package into the "reports" folder. If you wish to host multiple reports on the same web server, you can extract multiple packages under the "reports" folder. To ensure cleaner URLs when displaying the reports, remove the "sasreportpkg" extension from the unzipped repository.

So far, I have just created the folder structure and extracted two report packages into it.

The next step will be to build the Dockerfile.

Let me provide some insights into the file's content.

Describes the source image that includes a web server, specifically nginx, running on the Alpine Linux operating system.
Defines the working directory where nginx stores the files that will be served on the web.
To execute specific commands, it switches to the root user.
To enhance security, the OS is patched to minimize potential risks.
The files from the current folder are copied to the designated WORKDIR location.
The permissions on the copied files are modified accordingly.
A file named "data.txt" is created, which currently contains a list of folders under the "reports" directory. Although not immediately useful, it will be utilized in a later stage.
Information regarding the exposed port is provided.

With the utilization of this Dockerfile, you can now construct a Docker image by executing the subsequent command:

docker build . -t reports-hosting

Executing this command in the directory where the Dockerfile is located will generate an image labeled as "report-hosting". This label can be utilized to launch a container and verify the successful creation of the image. To initiate a container using the "report-hosting" image, the subsequent command is employed, which also exposes port 8080 on http://localhost:8080.

docker run -it -p 8080:8080 reports-hosting

The container will initiate in interactive mode, enabling the display of the web server's log.

By using a URL similar to my example, the report elements that were chosen to be exported can be viewed. Here are examples using my two exported reports:

http://localhost:8080/reports/Retail%20Insights/

http://localhost:8080/reports/Warranty%20Analysis/

You can now proceed to register the image in a repository for future deployment in Kubernetes. Although this approach is acceptable, it has a minor drawback: the end-user must be aware of the specific URL to access the report. This is where the usefulness of the "data.txt" file, created during the build process, comes into play. Let's explore its significance further.

Displaying the list of available reports

As you are aware, we have stored the extracted report packages on a web server. Consequently, we have the capability to host HTML files as well, which simplifies the utilization of the container.

To proceed, navigate to the directory where the Dockerfile is located and generate a new file called "index.html".

Ensure that the content of this file matches the following format:

Here is the rendered page:

Allow me to provide an explanation of the HTML code.

At line 12, there is a placeholder designated for the available reports. This placeholder will be filled with data by the generateList function. This function uses the data.txt file, which is created during the image build process, to generate a list of links to the reports. The getReportList function, called on line 21, retrieves the list of reports from the data.txt file and creates an array of URLs for the reports.

Updating the image

In the preceding section, you were shown the process of creating a "home page" for the image. Regrettably, these modifications will not be immediately visible in the image. To observe the changes, it is necessary to reconstruct the image and initiate a fresh container. Therefore, it is advisable to halt the currently active container (if not already done). Once completed, proceed with executing the same set of commands as before to construct the image and launch the container.

docker build . -t reports-hosting

docker run -it -p 8080:8080 reports-hosting

You have successfully generated a fresh image, and the updated container will showcase the modifications. This is the recommended approach for manually updating the image. Ideally, this entire process can be automated by utilizing a git repository and a CI/CD workflow.

Automating the deployment process

Previously, we have observed that the SAS Viya CLI can be leveraged to extract the report components in batch. Subsequently, we can employ OS commands to unzip the produced report package. Afterward, execute the build command and ultimately publish the code into a repository. Provided below are the necessary commands to accomplish this task:

git clone https://github.com/me/build-report-container.git
cd build-report-container
sas-viya reports build-package --id cbf97b0a-457d-4b4f-8913-547e0cdf390c --output-file report --output-location /reports
unzip -d "/reports/Retail Insights" "Retail Insights.sasreportpkg.zip"
rm "Retail Insights.sasreportpkg.zip"
git commit -m "Update Retail Insights"
git push originmain

The above code assumes that you possess a pre-existing git repository that can be accessed at: https://github.com/me/build-report-container.git

Once the git repository undergoes an update, it can initiate a CI/CD process to verify the code, construct the Docker image, and store it in the GitHub image repository. Furthermore, you have the option to automate the deployment process in your Kubernetes environment. Since these CI/CD processes vary depending on the git provider, I will not delve into the specific steps in this article. However, if you require further details on this topic, you can refer to the documentation provided by GitHub, for GitLab.

Conclusion

Throughout this article, we have demonstrated how SAS report packages can be utilized to showcase SAS Visual Analytics insights without the need to connect to the SAS Viya environment. This opens numerous possibilities in terms of usage and providing reports to any size userbase. In addition to displaying the exported package as-is, I’ve also shown in this article, how you can also personalize the index.html file we have created to seamlessly integrate objects from various reports onto a single page. The extent of customization is virtually limitless.

For a deeper exploration of the available options to interact with the report objects, we recommend referring to articles that delve into the SAS Viya SDKs.

The code for this article is available on GitHub.

Find more articles from SAS Global Enablement and Learning here.