As we saw in the previous article in this series, the goal of the SAS Viya API Wrappers for JS is to facilitate the development of custom web applications that can, for example, use the SAS Compute Server to populate prompts. One of the use cases is to create dynamic prompts for SAS Viya jobs. In this article, I will walk you through the steps of building dynamic prompts. This first example will help you mirror the capabilities that SAS provides out-of-the-box (more information) in a custom web application.   Using SAS Viya Wrappers for JS   The SAS Viya Wrappers for JS are designed to be used as a CDN package as well as inside a NodeJS based application via npm installation. Using a CDN, you can write the application in your favorite text editor or inside SAS Studio when creating a SAS Viya job. Using the npm installation method, you need to configure NodeJS and install the required dependencies using npm. In this article, we will cover using the CDN. A later article will explain how to use the SAS Viya API Wrappers for JS within a NodeJS based application. To use the library inside your web page, you need to import it into an HTML script tag like this one:   <script type="importmap" crossorigin="anonymous"> { "imports": { "sas-wrappers": "https://cdn.jsdelivr.net/npm/sas-viya-api-wrappers-js/dist/sas-viya-api-wrappers-js.js" }, "integrity": { "https://cdn.jsdelivr.net/npm/sas-viya-api-wrappers-js/dist/sas-viya-api-wrappers-js.js": "sha256-o5E56OSVRTSJlYXb+/M2vL+Dj2Q8o59+WsrVOBKolwU=" } } </script>   Please note that you should update the hash key in the integrity each time the sas-viya-api-wrappers-js.js is updated. If the hash is not correct, you will see an error in the Developer Tools of your browser. For more information about the importmap type for script, please refer to this documentation.  This declaration makes the library available in the web page, and it can be referenced as sas-wrappers in other HTML script tags on the same page using an import statement like this:   <script type="module"> import { ComputeSession } from 'sas-wrappers' const computeSession = new ComputeSession({baseURL : 'https://server.demo.sas.com', contextName : 'SAS Job Execution compute context'}) // Remaining code </script>   You now have a SAS Compute Server session. This session object can then be used to call the various methods provided by the library to get a list of libraries, tables, columns, and values.   The use case   In this example, the web page will display dynamic prompts in the form of HTML select tags and execute a SAS Viya job using the selected values. To improve the look and feel of the application, we will use the Bootstrap library. The resulting prompt will look like this:   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   The HTML code WARNING: images are based on version 1.2.4 of the library. Starting with version 1.2.5, the method signatures have changed to pass an object instead of a list of parameters.   Let's start with the HTML head section where we import the different libraries.     As you can see, we import the CSS stylesheet from Bootstrap and the sas-viya-api-wrappers-js.js from jsDelivr CDN hosting. The body element is then defined with the following class "container-fluid". Next, the top of the form element contains some layout elements and, most importantly, the two hidden elements used to invoke the SAS Viya job:     All select boxes are defined like this:     And finally, you have the Submit button. While the HTML tags define the layout of the application, the JavaScript code is responsible for handling the user interactions. At the bottom of the body element, we create a script tag with the following code:   <script type="module"> import { ComputeSession } from 'sas-wrappers' const computeSession = new ComputeSession({baseURL: 'https://server.demo.sas.com', contextName: 'SAS Job Execution compute context'}) // Remaining code </script>   In the rest of the code, we define a function to generate the HTML option elements within the HTML select elements:     This function takes two parameters:   Target is the id of the HTML select element to populate. Options is the data set used to generate the HTML option elements.   From line 107 through line 111, a dummy option is created and selected by default. This forces the end user to select a value in order to move forward in the selection process. From line 112 through line 117, the HTML option elements are created and appended to the select element. Finally, the select element is enabled to allow user selection. To simplify interaction with the various HTML select elements, each is bound to a specific JavaScript variable. For example:   const librarySelect = document.getElementById('librarySelect')   Let us move on to the next part, which will fill the librarySelect element:     The first step is to call the getLibraries method from the computeSession object. This method sends a request to the SAS Compute Server session to retrieve a list of libraries defined in the server context. This method is asynchronous. This is the reason for the use of the await keyword. Once the library data is retrieved, we execute the populateDropdown function using the data and populating the options in the librarySelect element. So far, we have created the various HTML select elements, and only the librarySelect element has been populated with data. We need to define what happens when the end user changes the selected value. The following code does this.     As you can see, the first task of the function is to clear the list of options for the different elements: tableSelect, columnSelect and valueSelect. The elements are also disabled to prevent selection. Then, the getTables method is called and the currently selected value for the librarySelect element is passed to the method as a parameter. Once the method returns data, the rest of the function is executed and the populateDropdown function is executed to populate the tableSelect element with the retrieved data. If you go through the rest of the code in the script tag, you will see that onchange functions have been assigned to each element to handle the selection. Finally, we close the script tag and add another script tag to import the necessary Bootstrap JavaScript files.   The deployment   This web page can easily be copied into the HTML form of a SAS Viya job. The purpose of this article is not really to demonstrate the capabilities of SAS Viya jobs. For this reason, the code for the job is as simple as a proc print that accepts the various variables passed from the form when submitted.   proc print data=&librarySelect..&tableSelect ;  where &columnSelect = "&valueSelect" ; run;   The macro variables are automatically generated based on the name property of the select elements. For example, the columnSelect macro variable refers to the value of the select element having columnSelect as name (line 82).     Note: This code is oversimplified and assumes that the valueSelect macro variable doesn't contain double quotes in its value. If there are risks that the value contains double quotes or other special characters, you should use the proper macro quoting functions.   The demo     About portability   The SAS Viya API Wrappers for JS has been designed to ease the build process of web pages for job prompts. One of the benefits of the library is that you can host the web page with the SAS Viya Job, but also on a standalone web server if you want to integrate it with other HTML elements on your page. Using the same HTML page as above, you can quickly adapt the form element to use fully qualified path for the SAS Job Execution web application and the path to the program to be executed. You need therefore to adapt the two elements on the HTML page:   The form element The input element named:_program   The form element action property should contain the hostname like this:   <form id="form" action="https://server.demo.sas.com/SASJobExecution/" class="form justify-content-center w-50 mt-3 mx-auto" target="_self">   The input element should be adapted like this:   <input type="hidden" name="_program" value="/Public/Demo/Jobs/SASViyaAPIWrappers_CDN" />   Where the value is set to the SAS Content location where the job is saved.   After changing these parameters, the HTML page will work fine when saved along with the SAS Viya Job in SAS Viya, but it will also work when hosting the HTML page on an external web server. You can even adapt the web page a bit more to display the result of the job execution on the same page as described in this article: How-to display results from a SAS Viya Job in the same page?   Conclusion   In this first example, we have seen how we can use the library to ease the development of dynamic prompts. The biggest difference with the solution that SAS provides out-of-the-box, is that we are using HTML tags and the content of the form is generated on the fly based on the data extracted from the SAS libraries available in the SAS Compute Server session. This approach while requiring more code than when using the SAS provided library also gives more flexibility to adapt the display of the form elements and their behavior. This is what you will see in the next article in the series.   The code for this article can be found here.   If you have ideas about how to improve the library code, please don't hesitate to contact me.   Articles in this series are:   SAS Viya API Wrappers for JS – Integrating SAS Compute Server into a custom web application made easy   SAS Viya API Wrappers for JS – Building dynamic prompts for SAS Viya Jobs (this article)   SAS Viya API Wrappers for JS – Building advanced dynamic prompts for SAS Viya Jobs     Find more articles from SAS Global Enablement and Learning here. ... View more

As we saw in the first article in this series, the goal of the SAS Viya API Wrappers for JS is to facilitate the development of custom Web applications that can, for example, use the SAS Compute Server to populate prompts. One of the use cases is to create dynamic prompts for SAS Viya jobs. In this article, I will walk you through the steps of creating "advanced" dynamic prompts. A first example helped you mirror the capabilities that SAS provides out-of-the-box (more information). In this example, we will see how to create dynamic prompts, customize the look and feel of a selection element with checkboxes, sliders and also add business logic to force users to select multiple values before submitting the job.   Using SAS Viya Wrappers for JS   The SAS Viya Wrappers for JS are designed to be used as a CDN package as well as inside a NodeJS based application via npm installation. Using a CDN, you can write the application in your favorite text editor or inside SAS Studio when creating a SAS Viya job. Using the npm installation method, you need to configure NodeJS and install the required dependencies using npm. In this article, we will cover using the CDN. A later article will explain how to use the SAS Viya API Wrappers for JS within a NodeJS based application. To use the library inside your web page, you need to import it into an HTML script tag like this one:   <script type="importmap" crossorigin="anonymous"> { "imports": { "sas-wrappers": "https://cdn.jsdelivr.net/npm/sas-viya-api-wrappers-js/dist/sas-viya-api-wrappers-js.js" }, "integrity": { "https://cdn.jsdelivr.net/npm/sas-viya-api-wrappers-js/dist/sas-viya-api-wrappers-js.js": "sha256-o5E56OSVRTSJlYXb+/M2vL+Dj2Q8o59+WsrVOBKolwU=" } } </script>   Note that you should update the hash key in the integrity every time the sas-viya-api-wrappers-js.js is updated. If the hash is not correct, you will see an error in your browser's developer tools. For more information about the importmap type for script, please refer to this documentation.  This declaration makes the library available in the web page, and it can be referenced as sas-wrappers in other HTML script tags on the same page using an import statement like this:   <script type="module"> import { ComputeSession } from 'sas-wrappers' const computeSession = new ComputeSession({baseURL: 'https://server.demo.sas.com',contextName: 'SAS Job Execution compute context'}) // Remaining code </script>   You now have a SAS Compute Server session. This session object can then be used to call the various methods provided by the library to get a list of libraries, tables, columns, and values.   The use case   In this example, we will demonstrate how to customize the form elements of the SAS Viya job to force users to select multiple values before the Submit button is enabled. In addition, we will see how we can use checkboxes instead of the HTML select element for multiple selection. At the same time, our page will render the result of the job execution on the same page, allowing the end user to see the selection and the result on the same page.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   The HTML code   WARNING: images are based on version 1.2.4 of the library. Starting with version 1.2.5, the method signatures have changed to pass an object instead of a list of parameters.   Let us start with the HTML Head section, where we need to import the different libraries.     As you can see, we import the CSS stylesheet from Bootstrap and the sas-viya-api-wrappers-js.js from jsDelivr CDN hosting. We also define the css for the iframe element. Using an iframe is the technique used to display the result of the job on the same page as the prompt.   The body element is then defined with the following class "container-fluid". The top of the form element contains some layout elements and, most importantly, the two hidden elements used to invoke the SAS Viya job:     If you are familiar with SAS Job Execution and building HTML forms, you may have noticed that the hidden input element for _program has been defined as the path to the job.   By default, all elements in the form are disabled. We will enable them later using the JavaScript code. This will allow us to dynamically enable/disable the element based on some business rules.   After the form element, we define the iframe element that will receive the result of the job execution.     The final HTML element is a modal that is displayed while data is being retrieved from the server. The modal displays a spinner when a call to the REST APIs is made and disappears when the UI is ready for user interaction.     That's it for the HTML code. The rest of the body element will be JavaScript code. We start with the code to start a Compute Server session:   <script type="module"> import { ComputeSession } from 'sas-wrappers' const computeSession = new ComputeSession({baseURL: 'https://server.demo.sas.com', contextName:'SAS Job Execution compute context'}) // Remaining code </script>   To determine if we can submit the form, we will do some basic validation. To store the information about the fields that have been validated, we initialize an empty array.   const validFields = []   We will add element ids to this array if they are valid, and then check the contents of the array to enable or disable the submit button.   We then have a few functions to populate the dropdown, checkbox, and range elements:         As you can see in the code above, the slider element is populated based on a specific SQL query. The query is generated on the fly based on the value of the regionSelect property. The generated code is used to call the executeCode method of the ComputeSession. The result of the code execution is then used to adjust the properties of the HTML element.   The final function is the enableSubmit function, which checks the contents of the validFields array to determine whether or not the job can be submitted:     Now that the functions are defined, we have everything we need to start implementing the business logic. To interact with the HTML elements, we will simply define variables that hold a pointer to the DOM element.     As you can see, the loader variable has a different definition. This is because we are creating a modal using the bootstrap library. Setting the background to static disables any interaction while the modal is displayed. This means that there is no way to close the modal by clicking outside of it.   Let's move on to the business logic. The first action that occurs is the populating of the regionSelect element. We will first display the loader modal and then retrieve data from the compute server. As soon as we get data, the selectRegion element is populated and the modal is closed:     We will then go on to define what happens when the user selects a region of interest:     As you can see in the code, selecting a region triggers a few actions:   Display the loader modal Retrieve value for the types Populate the typesCheckboxes element Populate the priceMax slider Enable the priceMax slider Set the priceMaxValue to display the current value of priceMax slider Populate the horsepowerMax slider Set the horsepowerMaxValue to display the current value of horsepowerMax slider Enable the horsepowerMax slider Add or remove the regionSelect value to the validFields array based on whether a value has been selected Hide the loader modal Execute the enableSubmit function to enable or disable the submit button   Nearly the same logic applies for the typesSelect:      As you can see at the beginning of the function, we retrieve the value of the regionSelect element to create a filter and display only the types available in a specific origin.   On lines 270 through 274, we check the number of checkboxes in the typesCheckboxes element that have a state of checked. If we have more than one checked element, the typeCheckboxes element is added to the validFields array. If not, it will be removed from the array. This means that we should have at least two values selected for this element to be considered valid.   We then have two event listeners for the scope. The event listeners will display the selected value. This is not mandatory, but it informs the user of their selection.     The last bit of JavaScript is to handle form submission. By default, submitting the form will call the job and display the result in an empty page. This is not the behavior we want to implement. We want the results to appear in the iframe below the form. This is the role of this event listener.     As you can read, we prevent the default behavior to occur and then we create the URL parameters and append them to the server URL. We then set src attribute of the iframe to that new URL. As a result, each time we submit the job, the src attribute will be updated and the iframe will execute the job.   The deployment   Now that we have seen how the web page was created, it is time to see what the SAS code looks like.   SAS provides a macro to transform the parameters passed to the job. The macro is available here. I copied the macro code at the top of the SAS code and then wrote the following code that calls the macro to create two macro variables: inTypes and inDriveTrains.   %param_list(mvar=types, outvar=inTypes, dlm=%str(,), quote=y) %param_list(mvar=drivetrains, outvar=inDrivetrains, dlm=%str(,), quote=y)   I only did this for these two variables because they can return multiple values for the same parameter and we want to build a list of selected values to filter our graph.   The graph is generated with the following code:   ods graphics / reset width=6.4in height=4.8in imagemap; proc sgplot data=SASHELP.CARS; hbar Make / response=Invoice group=Type groupdisplay=stack; xaxis grid; where type in (&inTypes) and drivetrain in (&inDrivetrains) and horsepower < &horsepowerMax and MSRP < &priceMax; run; ods graphics / reset;   As you can see, the macro variables are used in the where clause to do the filtering of the data.   The demo     The portability   As we have seen in the previous articles, one of the goals of the SAS Viya API Wrappers for JS is to allow the same code to be executed from the SAS Job Execution web interface as in the demo or from a standalone web application. In this example, there is no need to update the program or the form action when moving the web page from the SAS Viya Job HTML form to a standalone application. The reason is simple. In the previous example, we first submitted the job from the attached HTML form. As a result, we could use some specific parameters for the action and for the program name. In this article, we have already made these changes to display the result of the job on the same page. This makes it even easier to migrate the web page from the job definition to a standalone server.   While the code doesn't need to be modified to migrate to a standalone web application, the CORS configuration of the environment needs to allow connections to SAS Viya from a remote location. Therefore, you need to adjust the CORS configuration properly if the server name of the web server hosting your web application is different from the SAS Viya server name. For more information about CORS configuration, see the following articles:   Configure Cross-Origin Resource Sharing for SAS Viya for REST API’s an... - SAS Support Communities All about CORS and CSRF for developing web applications with the SAS Visual Analytics SDK   Conclusion   Using the SAS Viya API Wrappers for JS makes it easy to create simple or advanced forms for SAS Viya jobs. With this library, you can focus on the user experience and designing the UI you want. The library hides the complexity of retrieving data from SAS to populate HTML elements with dynamic data. You can design your interface the way you want and just transparently retrieve data from the server.   The code for this example can be found here.   If you have ideas about how to improve the library code, please don't hesitate to contact me.   Articles in this series are:   SAS Viya API Wrappers for JS – Integrating SAS Compute Server into a custom web application made eas...   SAS Viya API Wrappers for JS – Building dynamic prompts for SAS Viya Jobs    SAS Viya API Wrappers for JS – Building advanced dynamic prompts for SAS Viya Jobs (this article)     Find more articles from SAS Global Enablement and Learning here. ... View more

Building web applications is one of the easiest approaches to provide data insights to a large amount of users. SAS Viya provides out of the box HTML data tags which can be used to build forms for SAS Viya Jobs as described in this article and documented here. This approach is handy as you can use HTML tags and populate the drop-down boxes with data coming directly from SAS. When the selection is done, the selected values are passed to the SAS Viya Job and code is executed based on these values. You can use the JavaScript library to build simple forms for your SAS code. As soon as you start building more advanced forms or integrate jobs into an existing web application, it can become more complex to write the code. In this article, you will learn how you can build a reusable set of JavaScript/TypeScript classes which can then be used to build customized forms or integrate easily with React components.   Requirements   A SAS Hackathon team has asked for mentoring on how to build a form for a SAS Viya Job. The team wants to pass multiple values to the job. They tried to use the SAS provided JavaScript library to build the form, but they want to add some business logic in the user interface. They want to display a list of checkboxes from which the user should at least select two values before they submit the form and execute the SAS Viya Job. While this seems easy to achieve, changing a select box into a list of checkboxes is not so obvious. Using the SAS provided JavaScript library, you can create a select HTML tag which supports multiple selections. You can also make the different elements dependent on each other by building cascading prompts. But you can be limited in the business logic you are implementing because the JavaScript library hides the complexity and doesn’t let you do a deep integration. This is where I come in and my creativity for solving custom web applications starts. My idea is to build a few functions which would let the web developers interact with the SAS Compute Server to build a dynamic web interface.   The objective is to provide nearly the same functionalities as the SAS provided JavaScript library, but in a less restricted approach. While the SAS provided JavaScript library provides HTML tags which can be inserted in a web interface, the SAS Viya API Wrappers for JS would just provide the needed infrastructure to get a list of:   Retrieve Compute Server contexts Start a Compute Server session Retrieve a list of libraries from the active Compute Server session Retrieve a list of tables from a library Retrieve a list of columns from a table Retrieve the values from specific column Execute SAS code to retrieve data from the Compute Server session Close the Compute Server session   This would basically cover the needs of a web developer when building a custom web application which integrates dynamic data into forms.   SAS Viya API Wrappers for JS   What the SAS Viya API Wrappers for JS is not: a replacement for the SAS Viya Job and the SAS Viya Job Execution. The library is tool which can be used to reduce redundant code in multiple applications and hides the relative complexity of working with the SAS REST APIs. Based on my own experience, you often end-up rewriting similar code to call REST APIs for authentication, to start a Compute Server session, to retrieve a list of libraries, tables, columns, values, …   In addition, if you are new to SAS REST APIs, you might find difficult to interact with them as you are maybe not familiar with the SAS Viya architecture. The wrappers are there to help you and hide a bit of the complexity behind classes with methods which will allow you to be more productive.   The wrappers are made available as classes which can be imported into your web page from a CDN link or into your Node based application through npm install and traditional import statement.   The npm package can be found here. The CDN link is this. And the GIT repository is available here.   The APICall class   At the heart of the library, you have the APICall class. When instantiated, the class can execute calls to a specific REST API endpoint. When you create a new object based on it, you need to pass a few parameters:   {string} baseURL - The SAS Viya server. {Link} link - A link object that contains the method, rel, and other required information. {Headers} headers - The headers to include in the request. {string} data - The data to include in the request body. {URLSearchParams} urlSearchParams - The URL search parameters to include in the request.   The baseURL contains the URL of the SAS Viya environment. For example: https://server.demo.sas.com   The link is an object which provides information about the API endpoint that you are calling. It should contain information like the HTTP method, the HREF of the endpoint, the type of content that is expected. This information is used to build the HTTP request and interact with the endpoint.   If you are familiar with JavaScript/TypeScript, the headers and the URLSearchParams are instances of Headers and URLSearchParams.   The data parameter should be a string resulting from JSON.stringify() function. It used as the body of the HTTP request. Internally, the class will check if the user is authenticated before any API call. It will also handle the CSRF token which is required for most POST method calls to the REST APIs. The methods to authenticate and handle the CSRF token are private to the class instance. This means you can't use the method from the created object. The only methods you can call after creating an APICall object are the execute and logout methods . You can of course interact with the object properties using the dot notation. The code for this class is available here.   The ComputeSession class   This wrapper class uses the APICall class to perform different tasks through public methods like:   getComputeContexts() getLibraries({outputType: OutputType = 'data', searchParams: URLSearchParams} ) getTables( {libraryName: string, outputType: OutputType = 'data', searchParams: URLSearchParams} ) getColumns( {libraryName: string, tableName: string, outputType: OutputType = 'data', searchParams: URLSearchParams}) getValues( {libraryName: string, tableName: string, columnName: string, filters?: { column: string; value: string }[], searchParams: URLSearchParams} ) executeCode( code: string[], resultName: string ) deleteSession()   Each method can be called directly after instantiating the class like this:   const computeSession = new ComputeSession({ baseURL: 'https://server.demo.sas.com', contextName: 'SAS Job Execution compute context' })   As you can see, we are passing the SAS Viya Server name but also the compute context we want to use. If you don’t know which compute context should be used or you want to leave the choice to the end-user, you can use the getComputeContexts method. This will provide a list of the compute server contexts you have access to. If you want to reuse an authentication instance which created earlier with sas-auth-browser, you can reuse that instance and pass it as the third parameter when you instantiate the object. If you don’t have an instance, you will automatically be prompted to enter a user name and password using SAS Logon.   Most of the method names are meaningful enough not be described one by one. As you can see in most of the calls, the OutputType is preset to ‘data’. Using the OutputType as ‘data’ tells the method that data should be returned as a JSON object which can be consumed to display data in the HTML page. The other option is to set the OutputType to ‘api’. In that case, the method will return a JSON object which contains information which can then be passed to the APICall as a Link. Using that technique, you can extend the functionalities of the ComputeSession class to give more options to the users like registering or deleting tables, libraries, … These functionalities are not implemented in the current release of the package as the main intent is to consume data from SAS Viya Compute Server.   You should also be aware that the deleteSession . The deleteSession will stop the current compute context session, but will keep the user logged in. This way, a new compute session can be created using the already logged in user. Deleting a session is a good practice to reduce cloud usage and costs. Note that it also possible for administrators to limit the number of compute server sessions for a user. This means that if you don’t close your sessions, you may end up in a situation where the user is not allowed to start a new session until a previous one expires.   The code for this class can be found here.   Conclusion   At this point, you should have a better understanding about the usage of the SAS Viya API Wrappers for JavaScript. You can even extend the functionalities by cloning the repository and adding your own methods.   For more information about the SAS Viya REST APIs, please refer to SAS for Developers.   Articles in this series are:   SAS Viya API Wrappers for JS – Integrating SAS Compute Server into a custom web application made eas... (this article)   SAS Viya API Wrappers for JS – Building dynamic prompts for SAS Viya Jobs    SAS Viya API Wrappers for JS – Building advanced dynamic prompts for SAS Viya Jobs     Find more articles from SAS Global Enablement and Learning here. ... View more

In a previous article, I explained how you can use python programming language to build a dashboard where you can load data into CAS and visualize these data using the Dash python package. The article also covers how to score data using SAS Micro Analytics Services from python through the SWAT package.   In this article, I will cover the same concepts but this time using the Django framework. The main topics which will be covered are:   How to access CAS data from a Django web application? How to score data from a Django web application and display the results?   What is Django?   If you are familiar with the python programming language, you may have already heard about Django. On the Django website, you can read the following statement:  The web framework for perfectionists with deadlines. To paraphrase the statement, Django helps developers to build web application by providing an opinionated approach to web development in python. How does that translate in facts? Django provides a lot of out-of-the-box functionalities which can be used by web developers to quickly start their project and reuse code and functionalities provided by the package. This might still seem obscure. Django provides an easy way to define:   Views Models HTML pages Database integration   When you create a web application, you end-up writing and rewriting the same functionalities again and again. Django does all that wiring for you which gives the developers more time to focus on what is generating added value. To be more precise, the Views contain the business logic, what should be displayed when accessing a specific web url. The Models are an abstraction to database tables. HTML pages take the form of templates which can filled by data coming from the Models and manipulated by the Views based on the request send from the web browser. For the database integration, Django facilitates the integration by synchronizing the Models with the database of your choice (sqlite by default). In addition to these foundation elements, Django also provides an Admin interface which makes it easy to manager users, groups and Create/Read/Update/Delete (CRUD) operations on the database. Without any specific configuration, the Admin interface allows the users to browse the data and also to edit and delete data. As a developer, using Django helps you to focus on the code in your IDE and access the application in the browser. All the wiring between the web server and the database is handled by Django. This makes it a good choice for data scientists who are willing to expose their data on the web using their preferred language: python.   Setting-up the application   Setting up a Django project is simple. You should have python and pip installed on your machine. When done with python and pip installation, create a python virtual environment and activate it. You can then install Django using this command:   pip install django   After installation, you should execute the following command to create a project:   django-admin startproject mysite   In that command, you should replace mysite with the name of your project. In my case, I used django_mas as the project name. This command will create the structure of the project and generate most of the files needed to create the application. If you execute the following command, you will start the Django web server with a basic application running.   python manage.py runserver   As soon as the project is ready, you can add applications to it. Applications in Django can be considered as a set of related features for your web application. For example, if you are creating a web site for a library, you may create applications for:   User management Book registration Book borrowing Membership management   The benefit of this approach is that multiple developers can work all together on the project and work independently on their application. To create an application, you should execute the following code:   python manage.py startapp myapp   Where myapp is the name of an application you want to create. As soon as you create an application, you should register it in the project. This can be done by adding the name of your application to the settings.py located under the project configuration folder (the folder inside your project with the same name as your project).   INSTALLED_APPS = [ "django.contrib.admin", "django.contrib.auth", "django.contrib.contenttypes", "django.contrib.sessions", "django.contrib.messages", "django.contrib.staticfiles", "myapp", ]   As you can see from the list above, Django already registered a few apps by default. These apps are needed by Django to work properly and implement a bunch of functionalities you will use without having to write code. At this point, you should have a better understanding about how-to setup a Django project and create an application. If you want more information about this process, the Django website provides a good tutorial to start building applications.   The application   You have now been introduced to Django. It's time to show you what can built using Django and SAS Viya. The application is "basic", but already implements a few techniques to integrate SAS Viya data into a Django based web application.     The dropdown boxes at the top of the page are retrieving data from a table stored into the CAS server. The two cards are populated based on the user choices. The card on the left displays data coming from the CAS server while the card on the right displays results from the scored data. To score the data, a model has been:   created in SAS Visual Analytics registered in SAS Model Manager published to MAS   The application also implements another functionality which benefits from the integration of Django with a database. The web application registers information into a database to monitor the performance of the model. Storing the parameters passed to the model and result of the scoring, is important if you want to analyze the performance of your model across period of times. As you will see later, Django makes it really easy with just a few lines of code. Note: this demo application doesn't implement the user authentication. The username and password are hardcoded in .env file which is not included in the GitHub repository containing the code.   The code   As mentioned, the application uses two different sources of data: a CAS table and the MAS server. Let's focus first on the CAS related actions. To access the CAS server, you need to create a CAS session. As this will be used multiple times across the application, I've created a function for this under /django_mas/default/views.py:   def get_cas_session(request): if request.COOKIES.get("cas_session_id") != None: try: session_id = request.COOKIES.get("cas_session_id") cas_session = swat.CAS( f"{SERVER}/cas-shared-default-http", ssl_ca_list=CERTIFICATE, session=session_id, ) return cas_session except Exception: print(f"Session {session_id} is not valid!") cas_session = swat.CAS( f"{SERVER}/cas-shared-default-http", username=USERNAME, password=PASSWORD, ssl_ca_list=CERTIFICATE, ) return cas_session   As you can see in the code, the input parameter is a request object. This object is provided by Django and contains the information from the HTTP request. In our case, we are retrieving a cookie containing a cas_session_id. This session id is checked to validate if a session exists and is still active. If not, a new session is created. Reusing a session is a good practice to avoid starting too many sessions on the CAS server. As you can see in the code, we are using the SWAT package to create a CAS session. The SWAT package is provided by SAS and facilitates access to the CAS server from python. More information about the SWAT package and integration of CAS into python can be found here.   Creating views The next function in the file is the one that will be to render the web page.   def index(request): cas_session = get_cas_session(request) cas_session_id = getattr(cas_session, "_session") cas_table = cas_session.CASTable(name="Cars", caslib="Public") template = loader.get_template("default/index.html") context = {"origins": cas_table.origin.unique()} response = HttpResponse(template.render(context, request)) response.set_cookie("cas_session_id", cas_session_id, max_age=15 * 60) return response   This function creates a CAS session, accesses the Cars table located in the Public CAS library. An HTML template is then retrieved. If you are not familiar with HTML templates in general and with Django more specifically, you can find more information here. It will also be covered later in this article. We then define a context variable which uses the SWAT package behind the scenes. If you have already worked with Pandas dataframes, the syntax should be familiar to you. Finally, the function creates an HTTP response and sets the cookie with the session information. The next three functions defined in the views.py file are used to retrieve values based on the user choices. They are used to populate the different dropdown boxes and to retrieve the detailed cars information. As you will notice, these different functions are basically reusing the same structure and the one above. The biggest difference resides in the fact that instead of returning a HTML template, this time a JSON string is returned. This will allow the users to stay on the same page and to add interactivity to the web page.   def get_make(request): cas_session = get_cas_session(request) cas_session_id = getattr(cas_session, "_session") cas_table = cas_session.CASTable(name="Cars", caslib="Public") table_filter = f"origin=\"{request.GET.get('origin')}\"" data = cas_table.query(table_filter).to_frame() json_response = {"values": data.Make.unique().tolist()} response = JsonResponse(json_response) response.set_cookie("cas_session_id", cas_session_id) return response def get_model(request): cas_session = get_cas_session(request) cas_session_id = getattr(cas_session, "_session") cas_table = cas_session.CASTable(name="Cars", caslib="Public") table_filter = ( f"origin=\"{request.GET.get('origin')}\"&make=\"{request.GET.get('make')}\"" ) data = cas_table.query(table_filter).to_frame() json_response = {"values": data.Model.unique().tolist()} response = JsonResponse(json_response) response.set_cookie("cas_session_id", cas_session_id) return response def get_details(request): cas_session = get_cas_session(request) cas_session_id = getattr(cas_session, "_session") cas_table = cas_session.CASTable(name="Cars", caslib="Public") table_filter = f"origin=\"{request.GET.get('origin')}\"&make=\"{request.GET.get('make')}\"&model=\"{request.GET.get('model')}\"" data = cas_table.query(table_filter).to_frame() json_response = {"columns": list(data.columns), "rows": list(data.loc[0])} response = JsonResponse(json_response) response.set_cookie("cas_session_id", cas_session_id) return response   At this point, you have defined all the functions/views needed to build the web page. You may now wonder how they can be accessed. Django defines the link between the view and a URL in a specific file named: urls.py (located in the application folder).   urlpatterns = [ path("", views.index, name="index"), path("api/make", views.get_make, name="get_make"), path("api/model", views.get_model, name="get_model"), path("api/car-details", views.get_details, name="get_details"), path("api/price-prediction", views.score_data, name="score_data"), ]   The first url pattern defines the access to the root of your web site. In this case, http://localhost:3000/ The link is done with index function in the views file. And it will be identified as index. As you can deduct from the previous explanation, the second url pattern makes the link between http://localhost:3000/api/make and the get_make view. The last url pattern defines the link for the scoring view.   @csrf_exempt def score_data(request): data = json.loads(request.body.decode("utf-8")) with Session(SERVER, USERNAME, PASSWORD, verify_ssl=CERTIFICATE): result = mas.execute_module_step("msrp_prediction", "score", **data) record = ScoredData() predicted_data = {**data, **result} for key, value in predicted_data.items(): setattr(record, key, value) record.save() response = JsonResponse(result) return response   The code gets data from the request object. It then creates a session on MAS. To achieve this, we use the SASCTL package. This is a python package designed to ease the model management related tasks from python. For more information about the SASCTL package, please refer to the repository. A request is then made to score the data and a response is then returned to the browser. In the view, we are also saving the data to a database. This is achieved by the ScoredData model that is used to create a record and then save it to the database.   Creating the model Django provides the infrastructure to handle data models and make the integration with a database transparent. In our case, we have created a model in the models.py file.   class ScoredData(models.Model): ID = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False) Type = models.CharField(max_length=30) DriveTrain = models.CharField(max_length=30) EngineSize = models.FloatField() Cylinders = models.IntegerField() Horsepower = models.IntegerField() MPG_City = models.FloatField() Weight = models.FloatField() Wheelbase = models.IntegerField() P_MSRP = models.FloatField() Created_At = models.DateTimeField(default=timezone.now, editable=False)   The model will be responsible to store the data in the database defined in the project settings.py. In the default configuration, it will point to a sqlite database, but you can configure other databases based on your needs.   After updating the models.py file, you need to synchronize the database. This is done by executing the following commands from the root folder of the project.   python manage.py makemigrations python manage.py migrate   As soon as you execute these commands, you will be able to create new rows in the database using the score_data view. The next step is to create the HTML page which will be rendered by the index view.   Using templates To build web pages, Django uses a templating engine. This means you can create the structure of the HTML page and pass data to it. The templating engine allows also to split the HTML page into multiple blocks which can then be rendered conditionally. Following the logic above, the index view renders the index.html  which is defined as a block:   {% block content %} ... {% endblock %}   The block contains HTML code to render the static elements. It also includes the script tags which contains the JavaScript used to create the interactivity on the page and avoid page reloads. This will turn the application into a Single Page Application (SPA). The JavaScript implements the different functions required by the interface. The code is documented in the repository if you want more information about it. At the top of the index.html file, we indicate that the file extends the content of layout.html.   {% extends 'default/layout.html' %}   The layout.html  integrates Bootstrap library in the application and defines a navigation bar. Using Bootstrap assures consistent styling of the application in the web page and eases the development thanks to predefined CSS classes. For more information about Bootstrap. At this point, you have everything you need to run the application as demonstrated earlier.   Using Django Admin   Now that you have been testing your application, you might be interested in checking what was inserted into the database. You can therefore use the Django Admin page. To enable the Django Admin functionality, execute the following command to create a super user.   python manage.py createsuperuser   This command will prompt you for some information about the user you want to create. Don't forget the credentials as it will be your administrative user. You should then define the admin url in the urls.py located in the project folder:   urlpatterns = [ path("", include("default.urls")), path("admin/", admin.site.urls), ]   To adapt the display in the Admin page, you should define the list of variables you want to display.   class ScoreDataAdmin(admin.ModelAdmin): list_display = ( "Type", "DriveTrain", "EngineSize", "Cylinders", "Horsepower", "MPG_City", "Weight", "Wheelbase", "P_MSRP", "Created_At", ) admin.site.register(ScoredData, ScoreDataAdmin)   You are now ready to view the recorded data in the admin page.     Conclusion   While it is easy to create a web application using python and Django, you need to have a bit of JavaScript knowledge to build quality looking interfaces especially adding user interactivity. Using python for web development, interaction with CAS, scoring with MAS, is made easy thanks to python packages: SWAT, SASCTL and Django. You can build any custom application you want using these. Of course, the demo application doesn’t make use of authentication, but it can be easily added thanks to Django framework. For more information about building web applications using Python or JavaScript only, please refer to the following articles:   Open-source data visualization : Dash and SWAT Open-source data visualization : Dash, SWAT and SASCTL An approach to SAS Portal in Viya My first development with VA SDK using Node.js Using Node.js to develop with the VA SDK – a deeper dive Deeper integration of SAS Viya SDK content into your custom web application     Find more articles from SAS Global Enablement and Learning here. ... View more

In a previous article, I explained the process of creating a customized web application/page to incorporate Generative AI into a SAS Visual Analytics report. I have also written other articles that discuss various aspects of web development. From time to time, I receive inquiries about the deployment process for integrating the application into SAS Viya. In this article, I will provide a detailed guide on how to create a Docker image using the application developed in my previous article.   Deploying custom web applications in SAS Viya   After developing an application, whether you have utilized a development framework like ViteJS or simply created a few HTML pages with JavaScript and CSS files, the next step is to deploy the application and make it accessible within your SAS Viya environment. There are several approaches you can take to achieve this:   Hosting the files on a standalone web server alongside other web applications/pages. If you don't have access to a web server, you can choose to host your files on GitHub Pages or a specific web hosting company. Alternatively, if a web server is not available, you can deploy your application in the cloud using the same infrastructure as SAS Viya. For the first option, the process is relatively straightforward. You can simply copy your web application into the web server's structure, and your page will be accessible. This is likely the simplest option. However, it is important to consider the domain name of the web server. If the domain matches that of SAS Viya, there is no need to worry as the web server and SAS Viya will trust each other. However, if the domains are different, additional configuration is required to establish trust between the two domains. This can be achieved in SAS Viya by configuring CORS (Cross-Origin Resource Sharing) and CSRF (Cross-Site Request Forgery) as outlined in the following articles:   Sharing for SAS Viya for REST API’s and web developments   All about CORS and CSRF for developing web applications with the SAS Visual Analytics SDK   For the second choice, there is no requirement to possess your own web server. Instead, you can utilize the infrastructure offered by GitHub, GitLab, or any other web hosting companies. The advantage of this method is the ability to store your code in a repository and automate the deployment process. The article below explains how to set up this process for GitHub: Storing web pages on GitHub for consumption inside the SAS Visual Analytics Data-Driven Content object. It is also important to configure SAS Viya to trust the GitHub domain as mentioned in the article.   The third option involves deploying the web application/pages using the same cloud infrastructure as SAS Viya. In this scenario, you will need to create a Docker image and deploy it on the preferred cloud provider. Fortunately, the seemingly complex process is actually straightforward, as we will explore in the upcoming sections.   Building a Docker image   As an example, I will take the project from my previous article. There are several reasons why I chose this project:   A colleague asked me for guidance on deploying it in SAS Viya. The project is based on ViteJS and cannot be deployed as it is. It contains an API key that needs to be stored and used for building the application.   ViteJS is a great library that simplifies the development process. Once you have finished developing your project, you need to build the application. The build process generates a distribution for the application, which includes static files. These files can then be deployed on a web server for consumption. If you want to validate the process, it is possible, but I will not cover it in this article. Building a ViteJS application is as easy as running the following command:   npm run build   Executing this command will create a "dist" folder in the project, and the contents of this folder can be copied to a web server. While you can build the project within your editor, it is recommended to include the build process as part of your CI/CD (Continuous Integration/Continuous Deployment) pipeline. This automation not only saves time but also reduces the size of your repository. Only the code of your application should be stored in GitHub, for example, the remaining files like the "node_modules" folder and "dist" folder should not be stored in the repository as they can be generated by running specific commands. Here is the content of the repository seen from my editor:   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   And on GitHub     The "dist" and the "node_modules" are not saved on GitHub. Consequently, during the Docker image construction, the initial action will involve installing the node modules and generating the "dist" folder. Subsequently, the content of the "dist" folder will be copied into the web server as the second step of the process. It is understandable that these tasks can be repetitive, and our aim is to automate them as part of the Docker image creation process. This is precisely the purpose of the "Dockerfile".     The initial step in constructing the "dist" folder takes place between lines 1 and 8. Between lines 10 and 13, the creation of the Docker image that includes a web server and the web application occurs. To elaborate on these lines: Utilize a "builder" container that is based on a Linux Alpine image with NodeJS already installed. Specify the directory that will contain all the files in the app folder. Define an argument that will be passed to the command line during the creation of the Docker image. Store the command line argument in an environment variable within the Docker. Copy the package.json file from our repository to the app folder. This package.json file contains the necessary information for installing the node modules and specific commands for this project. Execute npm install to install the node modules, which will create the "node_modules" folder. Copy the contents of the repository into the "workdir". Execute npm build to generate the "dist" folder.   Utilize a different Docker image based on Linux Alpine with Nginx web server already installed. Copy the content of the "dist" folder from the builder image to the location where Nginx stores the files to be rendered on the web. Provide details about the port that is exposed for the Nginx web server. Start the Nginx server.   By using the Dockerfile in the repository, you can execute the following command to build the Docker image for our web server.   docker build . -t ddc_genai:v1.0 --build-arg GEMINI_API_KEY=$GEMINI_API_KEY   This docker command will create an image based on the content of the Dockerfile. It will tag the image as ddc_genai:v1.0 and pass the API key. The API key in this case will come from an environment variable. It means that if you have a machine with Docker installed, you should also have an environment variable named GEMINI_API_KEY which contains the API key to access the GenAI provider. The docker command is used to generate an image using the specifications outlined in the Dockerfile. The image will be tagged as ddc_genai:v1.0 and will include the API key. The API key will be sourced from an environment variable: GEMINI_API_KEY. This variable enables access to the GenAI provider.   Bonus: If you have Docker installed on your system, you can leverage it to quickly deploy the application. Once you have built the Docker image, simply run the provided command to start a container and access the newly deployed application.   docker run -d --name ddc_genai -p 3000:80 ddc_genai:v1.0   In this instruction, we give a name to our currently active container and specify that the application is actively running and listening on port 3000 of the host machine. Afterwards, we establish a connection between port 3000 and the internal port of the container, which is configured as 80.   Publish the image to Docker Hub   Now that we have established a procedure for generating the Docker image, it is possible to upload it to a repository such as Docker Hub or GitHub Packages. This article will outline the steps for uploading to DockerHub. Although the instructions are tailored for DockerHub, you can apply the same guidelines if you wish to upload the image to your own harbor. Keep in mind that since the build process involves the API key, making the image public on DockerHub will result in it being available to all users, and you may incur charges for Gemini usage. Therefore, this demonstration is purely for illustrative purposes and should not be implemented as is.     The workflow is triggered by every push to the "main" branch of the repository. It utilizes the latest version of Ubuntu to run all commands. Initially, the repository is checked out to prevent conflicting updates. Subsequently, authentication is performed against DockerHub using the provided username and password. Lastly, the build command is executed, and the image is pushed to DockerHub with the necessary argument. Please note that lines 18, 19, and 26 contain references to environment variables secrets.xxx, which are securely stored within the GitHub repository and will not be revealed. These variables are used for sensitive information like usernames, passwords, or API keys. They can be defined in the repository like this:     Once you have included the yml file in your repository, such as the one mentioned above located in github/workflows/, the workflow will be activated whenever there is a push to the "main" branch of the repository. For further details on GitHub Actions, please refer to the documentation.   Conclusion   As demonstrated in this article, the procedure for constructing a Docker image from an existing project is simple. You have the option to streamline this process using CI/CD methods provided by your Git service provider. Once the image is ready, your Kubernetes administrator can deploy it in the Kubernetes cluster like any other application. It is their responsibility to determine the most suitable configurations to adhere to the existing security standards. You can utilize the same namespace as SAS Viya or establish a separate namespace for your application. Opting to deploy it under the same Ingress controller is the easiest choice as it eliminates the need to configure CORS and CSRF. However, if you opt for deployment under a different domain, ensure to configure SAS Viya correctly.   Now, you are equipped with the knowledge to automate the image building process. You have the flexibility to generate the image whenever needed by pushing code to the "main" branch of your repository. You should not need to modify this process unless you intend to introduce additional parameters to the build process. If permitted by the administrator, you can even automate the application deployment with each push, although this may impact the production environment. I strongly advise incorporating more checks in the deployment process to verify the security of your application. This topic goes beyond the scope of this article as it is contingent on how your administrator enforces security in your deployments. Other articles related to deploying web applications are:   Deploy a custom web application in the cloud for Data-Driven Content object in SAS Viya 4   Storing web pages on GitHub for consumption inside the SAS Visual Analytics Data-Driven Content object   Deploy DDC Implementation Files in SAS Content Server via SAS Viya GUIs   Other articles related to web developments:   An approach to SAS Portal in Viya   Develop web applications series: Options for extracting data ... View more

Generative AI or GenAI is the current hot topic. While you may not have been surprised by the technology itself, you might have been surprised by the speed at which the technology has become mainstream.   In this article, I’m not here to discuss Generative AI but explain how you can integrate GenAI into SAS Visual Analytics reports to increase productivity.  See these articles by my colleagues if you are interested in GenAI:   Generative AI and Large Language Models Demystified by Beth Ebersole   Where does GenAI fit within the AI landscape by Sharad Saxena   The use case   The objective of the application is simplistic though it will demonstrate how easy it is to integrate content generated by a Large Language Model (LLM) into a SAS Visual Analytics report.   In our scenario, we want to generate text that could be used in an email to request a 10% discount on the price of a car. The user selects the car from a list and the model will generate the text asking the sales representative of car dealer to get the discount. The user has the choice to generate the text in different languages. Here is a demo of the application.     The technologies   The different components involved in the demo application are:   A Data-Driven Content object in SAS Visual Analytics A web page A GenAI modelIf you are new to SAS Visual Analytics, you may not know much about the Data-Driven Content object. This object is an object included in SAS Visual Analytics which allows the report designer to integrate an external web page in the report and pass data from and to the report. In other words, you can create a custom object which integrates as a native object into SAS Visual Analytics. For more information about the Data-Driven Content object, please refer to the documentation and the specific considerations when building the web page here.   For the GenAI model, I will use Gemini from Google. You can choose between other providers such as xxx but I chose Gemini because it offers free tokens and provides a good documentation to integrate the model in web applications based on NodeJS and Python. The choice I made is not based on functionalities or quality of the answers. It is purely based on cost for the demo application and my consideration for you to replicate and test on your own.  Gemini allows you to have 60 free requests per minute.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   The GenAI model   Gemini has easy to use documentation. Select the "Get started on the Web" section as it provides the needed information and examples to build your first application.   The first step is to generate the API key. Without that key, you will not be able to call the API. Be careful, you can only copy the key when you generate it. It means that you should store it properly to make use of it in your application. If you lose, the key you should create a new one and disable the old key.   This is the only task needed to configure access to the API. The rest will be done in the web application.   The web application   In terms of web development, you have also a lot of options. You can write plain JavaScript or TypeScript or you can use one of the available frameworks. In this case, I choose ViteJS as the development tool. It is really easy to use as a development tool to package the application and build the structure for different frameworks like React. So for this application, we will use the infrastructure provided by ViteJS, the functionalities provided by the React library to build the application and TailwindCSS to improve the layout of the application.   This article will not cover the installation of the different components on your development machine. You can follow the instructions provided by the different components to setup your environment. Installing and configuring ViteJS for React Integrating TailwindCSS into ViteJS   By default, SAS Viya restricts Cross-origin resource sharing. To allow access from your development server running on localhost, you need to configure SAS Viya properly. For more information, please refer to my article: Configure Cross-Origin Resource Sharing for SAS Viya for REST API’s and web developments.   To run the development server using HTTPS protocol, you can install and use this plugin.   The code   If you want to follow along with the following steps, you should have a running ViteJS web application based on React up and running and listening on https://localhost:3000 . TailwindCSS should be configured and SAS Viya should be configured to receive requests from a web server running on https://localhost:3000 .   The first step will be to create an .env.local file and store the API key in it. ViteJS will load the content of this file and look for any environment variables starting with VITE_. One nice aspect of this local environment file is that this file will not be copied to your git repository if you use version control on the project. This is useful as you don’t want to share your API key with others as you may have to pay for usage if you execute more than 60 requests per minute.   The file content should look like this:     You can then create two React components which will be used to display the text for the email and a bar to select the language. These components are stored under src/components in the project.   The documentation in the code should provide enough insights about the code itself.   Email component:     LanguageBar component:     With these two components, we have the needed elements to build the interface:     In order to integrate Gemini in our application we need to install the @google/generative-ai package. This can be done by opening a terminal, navigate to the location where your application has been created in my case: /Users/myuser/gitRepos/DDC_GenAI   And then executing: npm install @google/generative-ai   When done, you can replace the content of the /src/App.tsx file with the following code:     While you can go through the code and read all the comments, you should mainly focus on the fetchData function defined at line 24.   At line 27, the API key is imported and used to create model reference in line 28.   The lines 29 to 31 are used to generate the prompt based on the data received from the report. The prompt is then used on line 33 to call the model.   These fetchdata function is used to generate the text for the email. The remainder of the code is there to display the components and to handle the data received from the SAS Visual Analytics report (lines 49 to 62).   The prompt is generated on the fly using values passed by the SAS Visual Analytics report to the Data-Driven Content object and some arbitrary text defined in the application. The language selection is done in the web application which means that you can customize the prompt as you want.   Here is the prompt passed to the model through the HTTP request.     The report   The web application is now complete. It's time to use it in the report.   Here is the report structure:     For the Data-Driven Content object, the selected variables are:     And the properties of the object are:     The URL contains the information about the web server hosting the web application. In the development phase, it will be set to https://localhost:3000 . As soon as you will deploy the application, it should be adapted to reflect that move. Note that the change should also be done in the CORS configuration of SAS Viya.   Conclusion   Integrating GenAI content into a SAS Visual Analytics report can be achieved with the Data-Driven Content. With a few lines of HTML/JavaScript, you can generate content using Gemini, ChatGPT or any other model. In this example, we have arbitrary requested a 10% discount. This can also be driven by models deployed into MAS using SAS Intelligent Decisioning or SAS Model Studio combined with SAS Model Manager. In that case, the recommended price might be predicted by the model and the information can then be passed to the prompt and used to generate the text.   This text generation is basic as we have seen. You can of course add as many parameters and values as you want to the model prompt. Prompt engineering is a task on his own which should be mastered to get expected results from the GenAI model. It is far beyond the scope of this article. You can find more information about Prompt Engineering on this site.   The code for this article is available in this repository.   You have now the basics. It's up to you to dive more deeply into the GenAI world and imagine your own use case based on your needs.   For more information about Data-Driven Content, please refer to these articles:   Add rating functionality to your Visual Analytics report Using organization chart in your SAS Visual Analytics report Deploy a custom web application in the cloud for Data-Driven Content object in SAS Viya 4 Configure Cross-Origin Resource Sharing for SAS Viya for REST API’s and web developments   If you would like to see other examples about GenAI or have ideas topics around web developments and REST APIs, please don't hesitate to contact me or add a comment to this article. ... View more

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.   My first development with VA SDK using Node.js Using Node.js to develop with the VA SDK – a deeper dive Embedded Insights with SAS Visual Analytics SDK - SAS Support Communities   The code for this article is available on GitHub.     Find more articles from SAS Global Enablement and Learning here. ... View more

When executing SAS Viya Jobs with a prompt, the input form disappears as soon as you click the submit. This behavior may sometimes not be what you want for your end-users. In this post, I will describe how you can build HTML prompts for a job and display the result of the job execution on the same page. As a side gift, you will also see that building cascading prompts in HTML is an easy task.   SAS Viya Jobs   Before we deep dive into the actual code, I would like to explain what SAS Viya Jobs are. If you are familiar with SAS Stored Processes in SAS 9, the SAS Viya Jobs are the next generation of stored procedures for SAS Viya. It provides the same kind of functionalities as SAS 9 Stored Processes, but designed for the SAS Viya platform and cloud consumption. Behind the scenes, SAS Viya Jobs are using SAS Compute Servers and Compute Contexts started on-demand or made reusable to improve performance. For more information about implementing reusable SAS Compute Servers, please refer to this article.   When building SAS Viya Jobs, you can design it to prompt the consumers to provide input to the SAS code. You have different options to code your prompts:   XML JSON (new in SAS Viya LTS 2023.10) HTML   XML and JSON can be used to define metadata for your prompt. SAS will then generate the prompts which are rendered to the end-user. The look an feel of the prompts will be similar to SAS Studio's Tasks and Steps. This is most probably the best option if you are fine with the predefined layout and visuals provided by SAS.   On the other side, HTML is the best choice if you want to customize the user experience and use specific UI elements and colors. This is the option we will use in this article as it will provide the needed functionalities to build a custom web form and to display the result on the same page.   Interactive web forms   When building HTML forms, you often want to select data which are then used to filter another prompt. This functionality, often called cascading prompts, can be created easily in SAS Viya Jobs using JavaScript. Your first thought might be: “I don’t know JavaScript how should I proceed?” Don’t worry, SAS provides a JavaScript bundle to help you in the development of the HTML form. You only need to add the following script tags in the head section of your HTML page:   <script src="/SASJobExecution/resources/sap/ui/thirdparty/jquery.js"></script> <script src="/SASJobExecution/resources/dynamic.min.js"></script>   These two scripts will be in charge for loading the needed JavaScript functions to build interactivity. As you can see, they are using relative paths which means that they are hosted in your SAS Viya environment and you don't need to load the content yourself.   After adding these two scripts, you should initialize the function when the HTML page loads. This can be done with the following code:   <body onload="SASDynamic.init()">   The setup is now complete and you will be able to define prompts and dependencies. For example, you can retrieve the list of car brands from the SASHELP.CARS table using the following drop-down box:   <label for="cars">Choose a brand:</label> <select name="make" id="make" data-colname="make" data-library="SASHELP" data-table="CARS"> </select>   data-library specifies the name of the input library. Note that the library should be predefined, such as a global CAS library, for the Compute Context of the Computer Server. data-table references the name of the input table. data-colname provides the name of the source column.   When rendered in a browser with some styling attributes (or JavaScript), the following dropdown will be displayed:   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   If you want to define other drop-down boxes which are dependent on the car brand and type, this can be done using HTML code similar to this:   <label for="model">Choose a model:</label> <select name="model" id="model" data-colname="model" data-library="SASHELP" data-table="CARS" data-uses="make, type"></select>   If you compare this code with the previous, you will notice that we defined another property on the select element: data-uses. It can be used to defined which fields in the form should be used to filter the list of models.   If you want more information about defining dynamic HTML prompts, please refer to the documentation.   Creating the job   Now that you have a better understanding about interactive HTML forms for the SAS Viya Jobs, it is time to build the job.   In SAS Studio, click on New and select Definition under Job. In the Program pane, type the following code:   proc print data=sashelp.cars; where model = "&model"; run;   As you can see, the job will print the observations from SASHELP.CARS which have the value of model macro variable as model. The code is simple but it serves the purpose of the article. It shows how you can pass parameters from the form to the SAS code. The macro variable name should match the name of the input field in your HTML form.   In our case, the form is defined like this:     Displaying the form results into this:     At the top of the HTML code for the form, you see that we have three hidden input fields. The _program provides the name of the program to be executed which is retrieved from the URL of the job. The two _action fields are defining that the job should execute and display a wait message while executing the code.   After the closing form tag, we should add the following code:   <iframe id="results"></iframe>   This iframe tag will host the results from the job execution. In our case, it will display the results of the execution of the proc print defined for the job.   In order to display nicely on the screen, I've defined a style tag in the HTML and a title for the web page. The complete code looks like this:     In SAS Studio, you can add the code clicking the right pane to Associate a Form.     In the HTML Form pane, you can type the code about or retrieve it from this location.   Turning into a single page application   If you save the job at this point and retrieve the URL to execute it, you will notice that the job will execute but the form will disappear to display the results.     This is not what you would expect as I mentioned above that the result will be displayed in the iframe.   To display the result in the iframe, you need to add some JavaScript in the page. At the bottom of the HTML page just before the closing body tag, add the following code:   <script>     $('form').on('submit', (event) => {         event.preventDefault()         const urlParams = $('form').serialize()         const url = `/SASJobExecution/?${urlParams}`         $('#results').attr('src', url)     }) </script>   This code is executed when the submit button of the form is pressed. We are using jQuery to attach an event listener to the form element.   In the code, we retrieve the form fields and transform them into url parameters which are then passed to the url for the SAS Job Execution.   Finally, the last line defines the src property for the HTML element which has an idea of results. In our case, the element is the iframe.   There is one line of the code which I've not covered so far. The event.preventDefault() code prevents the normal processing of the HTML form. Usually, when you press the submit button of an HTML form, the input fields are cleared out and the form executes the action defined into it. In our case, this would lead to calling the job with the parameters and clear the form, but it will force the complete page to be refreshed with the results. Adding the event.preventDefault(), we explicitly tell the browser not to execute the form as it should but take the subsequent actions instead, which ultimately in our case means: set the src attribute for the iFrame. As a result, the job will execute and display the result in the iFrame as you can see in this demo.     Conclusion   Building interactive HTML forms for a SAS Viya Job is a simple task. With basic HTML coding experience and the SAS provided scripts, you can create dependent prompts which are using SAS data. If you want to improve the layout of the HTML page, you can write your own CSS styles or rely on other libraries like BootStrap. The benefit of preventing the default behavior of the submit button is to build a single page application which gives the opportunity to the end user to execute code using different input values and staying in the same page.   If you are interested in knowing more about the SAS Viya Jobs, please refer to the following articles:   Create a SAS Viya Job with a prompt using Task Prompts Create a SAS Viya Job with a prompt using HTML Prompts Add rating functionality to your Visual Analytics report     Find more articles from SAS Global Enablement and Learning here. ... View more

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:   All about CORS and CSRF for developing web applications with the SAS Visual Analytics SDK Deploy a custom web application in the cloud for Data-Driven Content object in SAS Viya 4 How to customize data export in SAS Visual Analytics? Using organization chart in your SAS Visual Analytics report The Data-driven Content Server for SAS Visual Analytics!   The code for this blog containing a simple application can be found on GitHub.   Find more articles from SAS Global Enablement and Learning here. ... View more