The concept of an autoexec file (specifically, an autoexec.sas file) has been around in SAS for many years.  SAS programs rely on a host of contextual information in the form of data locations (paths, file references or libraries), system options, predefined macro variables and many others.  Users find it beneficial to use autoexec.sas to execute pre-processing (you may consider them pre-'program') code because it saves time and simplifies maintenance of  execution code, allowing it to run on multiple environments with different settings.   SAS Viya Workbench provides you multiple environments to test, iterate and develop solutions at scale.  The ephemeral nature of Workbench instances, however, requires that you take certain steps to ensure that your autoexec specifications are recognised across those instances.  Here's a quick overview:   Remember to set up a home directory!   Many prior unsuccessful attempts at using autoexec.sas stem from omitting this first step.  As mentioned earlier, every Viya Workbench instance is spun up using containers and unless persisted, data on these containers is specific to the instance alone and go away with its deletion.  One therefore requires a persistent storage to house the autoexec.sas file, and this role is performed by the home directory.  Watch this quick video to learn how to set up home storage location.         As you might observe, this is fairly easy.  Note that users can create only one home storage location, which is automatically treated as the user's home folder only for subsequent workbench instances (not already running ones).   Create an autoexec.sas file   Keep an example autoexec.sas file ready.   You might like to keep things simple for the first test.  I typically test the same by defining a new libname (pointing to a location on my persistent storage) and then checking if this libname is automatically recognised in a future Workbench instance.  Note  this means you have to start a Workbench instance (without an autoexec.sas defined, yet), with storage attached, create a file, and then take steps to apply the same.  As shown in the following video:         Note: In the video, for convenience, we saved the test_autoexec.sas in our persistent storage area.  Ideally, however, you'd like to save this in your home directory for reasons which will soon be apparent.    Associate your autoexec.sas with the SAS session   To do this, we take advantage of the settings within the Visual Studio Code Extension For SAS, available here.  A bonus is that you can edit this settings file for any use of the Visual Studio Code extension for SAS (not just Workbench).  The following video shows you how.           It's easy to slip up here, so let me point out that you need to click on the tab named "Remote[xxxx.my,workbench.sas.com]" to get to the correct settings.json page.  Otherwise you only edit the Workspace settings, which are local to the session.   Further, why bother adding a new autoexec.sas file, when there seem to be some default autoexec.sas files already existing?  While you are free to edit those files directly, it might be convenient to add a new reference to your autoexec.sas file so that you can easily manage the same and maintain a separation between default autoexec settings and some settings which may be short-term or more dynamic in nature.   Another question could crop up regarding the need for a home directory.  In addition to providing some persistent storage, the home directory also happens to be unique to a user's profile, i.e. there can be only one home directory available.  On the other hand, there could be multiple other persistent storage locations defined, but the user's allowed to mount only one of them at a time.     Test your changes   Once you have made your edits, it's time to test if your changes work.  As you might observe in the following video, upon creating a new Workbench instance and directly calling a program using a libname MYTEST, I find that MYTEST has been automatically assigned,  proving that my autoexec.sas file works!         Have fun testing your autoexec.sas files.  Remember, they take effect only for subsequent Workbench instances that you create.     ... View more

In an earlier tip, we shared a GitHub repository with examples to help get started with SAS Viya Workbench.  Repositories from GitHub (and similar services such as GitLab or BitBucket) are not just for examples.  They are also used for source code management, collaboration and governance.   To optimise your experience working with ephemeral Workbench environments,  Git repositories help you with a centralised residence for your SAS or Python (and even production or development) code.     Option 1: Using the Extension   Let us look at two ways through which you access your code from Git repositories.  The first makes use of the built-in Visual Studio Code Git extension.  Watch the following video which shows how to use the Git extension to pull from a repository and start work in no time.       Some gotchas to look out for:   1. First, close the workspace folder in order to get the "Clone a repository" button come up on screen.     2. The sign-on to GitHub (or other provider) is shown as an example.  It's an optional step, but highly likely to be encountered, especially if you're planning to access a restricted / private repository. Note that Visual Studio Code server , which operates inside a container, may not be that readily 'aware' of the connections it needs, compared to something like Visual Studio Code running on your server, therefore may require authentication when interacting with external repositories.   3. Remember to choose your workspace folder (also identified by the $WORKSPACE environment variable) as the place where a local copy of your repository should reside.  Since Workbench instances are ephemeral, only contents saved in the workspace folder are persisted and available later, should you decide to access the code through another Workbench instance.   Before you commit your changes..   Assuming you have made changes to your code, it's time to commit your changes.  The extension comes in useful, but, as you might notice at the end of the following video, you might run into a problem when trying to commit your changes.       Git config - one more gotcha   Wait - you notice an error stating that Git has not been configured!  Any guesses as to the reason why, 🙂 ?  Recall that Workbench instances are ephemeral, and therefore settings necessary for interacting with a GitHub repository at a 'write' level (for example, committing changes and pushing them to a repo)  require git to be properly configured.  Note that I spelt git in lowercase, indicating that this refers to the 'git' command-line utility and not the Git repository.   Git configuration can be easily carried out via the VS Code terminal, using a git config command.  At a minimum, the user.name and user.email fields need to be set.  Additional configuration might be required for accessing more restricted repositories.       # Text within braces are placeholders git config --global user.name {your Git repo's username} git config --global user.email {email used to access Git repo}       Once you've done this, it's time to push your changes, as shown in the following video.  For other useful operations, you might like to refer to tutorials such as this.       Option 2: Using git commands   Users who happen to be comfortable with the git command-line utility can also use the same in order to clone, commit, and carry out other operations on a Git repository.  The same gotchas mentioned earlier apply.  Ensure you have carried out the git config statements and that you persist your local repo in the workspace folder.  If interested, you can refer this tutorial for more git commands.         Have fun porting your code across Workbench instances of your choice.   ... View more

Advantages offered by SAS Viya Workbench include fast availability of a compute environment, and support for multilingual analytics (Python or SAS, based on skills and preference).    When it comes to Python environments, however, users demand flexible and convenient package installation to aid rapid iteration and experimentation.  The default method is to use the standard Python package installer (pip) to install packages.  However, pip installs take a long time  and package installation becomes complex when there are many packages and dependencies involved.   This tip suggests the use of virtual Python environments to help isolate and manage your Python package installation.    Using this opportunity,  for informational purposes only, we also describe another Python installer utility called uv.  The uv package is written in Rust and claims to be 10x - 100x faster than traditional pip and pip-tools, through use of a global cache and better dependency resolution.  It follows a syntax very similar to pip, making it easy to adopt and use.  Check out its PyPi page for more details.     IMPORTANT: Use uv based on your own discretion.  The SAS Viya Workbench documentation specifies pip install as the standard approach to install packages.   This tip regarding uv is only meant as a suggestion and I recommend you first try it out on a local Python environment for experience.   Virtual Environment creation   Virtual environments in Python allow you to create separate sub-environments within an existing Python environment.  Any additional packages you install in the virtual environment are not accessible by the base (main) Python environment.  This provides you, the Python user, benefits such as isolation,  control over package dependencies, and rapid experimentation through different virtual environments.  As environment definitions can be persisted, you also have an option of discarding your work in case of issues, and reverting to the base Python environment.   Creating a virtual environment in Workbench is easy and can be achieved through the following commands (for e.g., through a Terminal window on Workbench's Visual Studio Code application):     # Create a virtual env - provide your desired name in place of new_env python -m venv new_env # Activate virtual env . new_env/bin/activate     The 'uv' angle: It's also possible to create virtual environments using uv.  Install uv, using pip, into your target environment just like any other Python package.  Once that's done, you can create a virtual environment and activate the same.     # Install uv and upgrade pip pip install --upgrade pip uv # Create virtual env using uv uv venv new_uv_venv # Activate virtual env . new_uv_venv/bin/activate     Note how the commands for creating a virtual environment using uv are similar to traditional Python commands, i.e. python -m venv <virtual_environment_name>.   Deactivation: In order to revert to the base  Python environment, use the deactivate command to leave the virtual environment.  This applies for both virtual environments created through venv or uv.     # Deactivate virtual env deactivate echo "deactivated system" # OPTIONAL - Remove virtual env folder rm -rf new_env     Package installation   Once you've activated a virtual environment, install packages  using the pip install command, either through a list of required packages, or a text file, conventionally named requirements.txt,  containing a list of packages.   Pip is a powerful utility which also provides other operations.  The pip documentation is a useful reference.     # Install packages pip install --upgrade -r requirements.txt     The 'uv' angle:  The uv command is as easy as the traditional pip command.  Just prepend the 'uv' command to a standard pip installation command, either specifying the packages as a list, or using a requirements.txt file.  As shown in the following snippet.     # Install packages from requirements.txt uv pip install --upgrade -r requirements.txt     Let's take a look at the effect.  Taking an example where a minimal set of packages (for e.g., torch for machine learning, plus some additional helper packages) were specified in requirements.txt, the following animated gif shows how quickly uv downloads the same (faster than pip).     A quick impression about uv's speed improvements   To form a quick impression, we specified an example requirements.txt file consisting of the following common machine learning and analytics  packages:     torch swat tensorflow matplotlib pandas flask     Note that this is NOT meant as an exact test, rather a rough assessment which was sufficient to form an initial impression.  We found that using uv took, on an average,  30% of the time compared to using traditional pip commands.     Note that the time to install can be affected by package composition and several other infrastructure-specific / local details.  uv provides its own claims and test details on its Python project page.  An assessment of uv is beyond the scope of this tip.   If you are interested in a detailed script containing the commands provided above, feel free to access them from this GitHub repository.   Have fun trying out package installation and virtual environment methods on SAS Viya Workbench and share your experiences. ... View more

SAS Viya Workbench is now available for you to accelerate your code development!  Here's a link to the product page on the AWS Marketplace: https://aws.amazon.com/marketplace/pp/prodview-oyybm2xk34dos?applicationId=AWSMPContessa&ref_=beagle&sr=0-1   Get Started!   As with any new software, you might feel a bit shy to try things out.  Guess what?  We've put together a set of tips that'll make you shed your inhibitions in a flash!  Take a look at  SAS Viya Workbench Examples,  our GitHub repo containing a number of    - Example datasets, - Python programs, and - SAS programs   which provide you an experience of how to rapidly develop and prototype analytics using SAS Viya Workbench.     Stay tuned for more tips in future! ... View more

Document embeddings (or vectors, as the fashionable like to say) have emerged as a popular area due to the focus on Generative AI.  Visual Text Analytics, a SAS Viya offering providing Natural Language Processing (NLP) capabilities, provides an option to train embeddings through the Topics node, backed by the Singular Vector Decomposition algorithm.  I encourage you to refer here for a detailed discussion of topics.     The purpose of this article is to highlight a sometimes overlooked task when applying document embeddings for purposes of similarity-based search.  Normalisation of vectors helps obtain relevant matches.     Why is this important?   First, let's consider vector embeddings.  Simply put, these are numerical representation of text contained within a document.  Represented as a series of columns in a table, each column refers to some feature (also known as a dimension) of the source document, and together, these columns represent the document as a whole.   Why do we need to transform a document into embeddings in the first place?  Text content can be represented in multiple styles and forms, making it hard to organise, classify and analyse.  Motivations for embedding documents include the following:    data standardisation - similar terms are packed as close numbers within dimensions rather than get treated as  distinct units feature engineering - data is organised under different dimensions each of which may carry different meaning transformation for downstream applications such as analytics and machine learning, for which numbers are more amenable masking - data is no longer represented as readable text, but as numerical proxies   Now, let's consider the definition of a vector.  In mathematics, a vector's a quantity that contains magnitude (length) and direction.  Therefore, it isn't just one number (which would make it a scalar) but a set of numbers which represent the number of dimensions.   This is an extremely useful property, since it allows for operations which measure how similar two documents are based on the distance between their vectors.  Let's take a simple case involving a two-dimensional vector.        Yes, I know.  Poor William's turning over somewhere in Stratford-upon-Avon, but that's the price you pay for fame.    The image above shows vectors for two documents depicted in two-dimensional space.  Given their coordinate points, vectors enable calculation of distance between the embedding, a simple and common implementation of which is Euclidean distance.  This works out to 1.414 (the approximate square root of 2).   As the graph also shows, the vector distance can be viewed as the deviation in direction between the two vectors.   A low value indicates that the two documents are more or less similar, which seems to be the case here, albeit to the horror of purists.   However, the utility of the above measure is limited!  The reason is that this distance is highly vulnerable to scaling differences which may have been introduced during the embedding training process. Note that embeddings could originate from different sources and we cannot take their representation as standard.  This also affects the extent to which we interpret any distance measure that's derived.  Is 1.414 small (indicating similar) or large (divergent)?   I'll never know until I use a standard.  This is achieved through a process known as normalisation.   So, what should I do?   The principle behind vector normalisation is intuitive.  Let's consider the same example again.     Let's introduce the unit vector.  The unit vector refers to the vector values within the small green box bounded by (1,1).  A unit vector is defined as a vector with a magnitude of 1.   A magnitude, simply expressed, refers to the length of a vector.  Recalling Pythagoras who used to haunt our geometry books, this can be calculated using the formula to calculate the hypothenuse of. a right angled triangle, namely,    Square root ( Sum of squares of dimensions)   Another name for the magnitude is norm, hence the term normalising the vector.  To arrive at a normalised value, you simply divide the individual vector values by the magnitude.  The resultant vector is a unit vector, which acts as a standard for carrying out similarity search and other vector-based operations.   In our simple example, the unit vectors work out to:   Document Dimension 1 Dimension 2 Text 1 3 / square root(90) 9 / square root(90) Text 2 4 / square root(80) 8 / square root(80)   Do it for me, please ?   Gladly.  Please refer here for a SAS program which takes in an input table (or dataset) with vectors, and normalises the columns to a magnitude of 1.     The business end of this program can be found between lines 197 to 329.  Notice that this program can run on both CAS and SAS (i.e. SAS 9 / SAS Compute or SAS Programming Runtime Environment) engines and uses array logic to normalise the vectors.  Also to be noted is the use of the dictionary.columns table which helps us identify all "vector" columns in the input table which conform to a given name pattern.  Highly convenient when dealing with typical vector data which does tend to run in the 100s of columns.  Imagine writing an array for each one of those!    Give the code a whirl and let me know your feedback.  You might also notice that the code has a lot of other programs wrapped around the same, a strong hint of my intention to also make it available as a SAS Studio Custom Step.  Soon.   I want to meet you, shake your hand, and shower praise upon you.   Cash would be better.  Actually, thank you, but no sweat.  I'm happy to answer further questions, though.  You can email me by clicking here.  Glad you enjoyed it.     ... View more

I gave myself what I considered a simple task - to design a macro that checks whether Python is available to a given compute or batch session.  As things turned out, I learnt a bit about SAS system options and environment variables used inside SAS sessions.    In a cloud-native world, most environments can be considered ephemeral.  Workloads can be intended for more than one predesignated compute environment.  Those environments may have different configuration.     Preflight checks, run through SAS macros prior to the main execution code, are extremely useful in assessing an environment for necessary characteristics.   Also, I found this task useful because it allowed the program to fail gracefully if it couldn't find Python.     Graceful failure, if accompanied with right level of log messages, can help the developer quickly take remedial steps.  It also helps avoid 'cleanup' or rollback situations where part of a program has already run and datasets may have been modified or created.         Access the Macro    The macro can be accessed from a GitHub repository I maintain for various utility SAS programs.  I also use them in underlying code of many SAS Studio Custom Steps (low-code SAS Studio components which promote ease of use, code reusability and automation).  Some of my custom steps happen to have proc python blocks, and in future, you may expect to see me including this macro in those steps.   Link to the Python check macro program:  click here Link to the GitHub repository (of utility programs):  click here Link to an example test code for the above macro: click here      How does it work?   We'll not venture too deeply into the inner workings of the macro's code here (which, at the end of the day,  is pretty simple), but highlight key decision variables which help in determining access to Python.  These can be understood through the following questions:   Does the SAS session know where Python is located?   This is informed by an environment variable called PROC_PYPATH.  As Scott McCauley describes the process in his article on configuring Python in SAS Viya,  PROC_PYPATH is set when configuring SAS Viya to access open-source languages, and provides a path to a Python executable invoked whenever PROC PYTHON is run.     Even if specified, does the Python executable really exist?   Environments can break and it's possible Python might have never been installed, installed incorrectly or installed somewhere else.  The macro carries out a check of the contents of the PROC_PYPATH variable to check if the python executable file (e.g. python3) mentioned actually exists and is known to the session.  Note that in batch sessions, sometimes, a path to Python may have not been mounted as a volume, an error situation which could be identified in this case.     Is LOCKDOWN enabled or not?   LOCKDOWN is a security-centric status in SAS servers which disables certain operations and access methods to protect the system.  Settings that allow access to external environments and languages like Python are disabled by default and have to be explicitly enabled.  Certain environmental variables control whether LOCKDOWN is enabled or not.  These include COMPUTESERVER_LOCKDOWN_ENABLE & BATCHSERVER_LOCKDOWN_ENABLE, applied to compute and batch server sessions, respectively.  Note that when they are set to 0,  LOCKDOWN is disabled for that SAS server!  This is not a desirable situation (even though it means that Python can run in that session) because it carries potential for compromise from a security perspective.     Are methods required to run Python enabled?     A final check is to ensure the following three access methods - PYTHON, PYTHON_EMBED and SOCKET - have been enabled.  This means they would form part of the values in an environment variable called VIYA_LOCKDOWN_USER_METHODS.   Although PYTHON_EMBED is specific to one way of running Python (using a submit block in PROC PYTHON), we include it as part of the check all the same.  You can edit PYTHON_EMBED  out if you don't want to perform this check.   When all these checks pass, a set of macro variables, passed as arguments to the macro, are populated with values that indicate there is no error, and also a description that states that a path to Python is available in this compute session and that Python has been enabled.   Even with all these checks, the macro should not be considered foolproof.  One callout is when Python is accessed in the SAS Cloud Analytics Services (CAS) server through proc cas inside a compute server session.  Even though the compute server is used in this case, the Python under question refers to the environment available to CAS, and may be further governed by a SAS External Language Settings File (EXTLANG).   Extlang provides its own messages back to the calling program in case a user without necessary privileges attempts to run Python through a CAS action.     At the same time, it seems a safe assumption to say that remaining situations warranting further checks are rare and can be considered edge cases.  Do feel free to write in if you have additional suggestions and pointers which can improve this macro!       Specify the macro within your SAS programs   The simplest way to use this macro within a SAS program would be to directly copy and paste it in your SAS program and then call the same.  However, as you may have noticed, the macro's code is pretty long (including comments :)).   Here's an alternative method which hopefully makes it easier to define the macro.  It uses the Filename statement which creates a reference to the URL where this macro is located, and then "includes" it in the SAS program.  This inclusion causes the macro to be specified (but not executed, yet) in your SAS session.   filename getsasf URL "https://raw.githubusercontent.com/SundareshSankaran/sas_utility_programs/main/code/Check_For_Python/macro_python_check.sas"; %include getsasf; filename getsasf clear; Of course, ensure you have a connection to the GitHub repository (you should, as long as your application's connected to the internet).  There's always copy-paste as your best friend should you find things difficult.   Where, within a SAS program, would you specify and call this macro?  While preferences and structures vary, I have found that it's useful to divide your code into "function code" and "execution code".  "Function code" is usually defined upfront and tends to consist of macros, any user-defined functions, or other modularised elements you would like to call in your "execution code".  You may like to define the macro within your "function code" and then call the macro (next section) in your execution code.  Of course, this is only a suggestion.  Use this wherever you like, as long as it works for you! :).     Call the macro   You typically call the macro at the start of your execution code.  First, define the following macro variables (you can name them whatever you like).   1. A macro variable for an error flag : Specify this variable as global so that it can be used downstream.  This macro variable represents a flag with a value of 0 indicating no errors from the check, and a value of 1 indicating some error. 2. A macro variable for an error message: Specify this as a global variable too. This is mean to hold a description of the error (or the absence of an error) that may have occurred.    An example is shown below:   %global python_error_flag; %global python_error_desc;   Next, call the macro.  You have a choice here.  The check depends on the type of SAS server - whether a compute server or a batch server - you happen to execute your workload from.   A compute server is the type of environment used when you open applications such as SAS Studio in the Viya platform.  A batch server is typically used for batch submissions made using the sas-viya command line interface (CLI) in batch mode.  Organisations may in some cases like to develop code using compute servers and then schedule them to run in batch.   If you neither know nor can control the target server,  the _env_check_python macro can be used.  It makes a determination about the server where the code runs and calls the relevant macro.   /* Note that the names of the error flag and error description macro variables are quoted when sent over as arguments - this is required.*/; %_env_check_python("python_error_flag","python_error_desc"); An important note is that the names of the error flag and error description macro variables are quoted when provided as arguments.  The macro is designed to take their names as references to the variables that need to be used.     If you do happen to know the type of target server, then either the _env_check_python_compute or the _env_check_python_batch macro can be called directly.  The syntax is the same.   For example,    /* In case of a compute server */; %_env_check_python_compute("python_error_flag","python_error_desc"); /* In case of a batch server */; %_env_check_python_batch("python_error_flag","python_error_desc");   Here's an example reference to the macro variables and result (for a successful identification of a path to Python).   Error descriptions, when error situations occur, differ according to the circumstances and stage of the check where they were found.  A quick read of the macro will provide you different error messages.         Acknowledgements   Thanks go out to a number of people who helped me in learning more about the variables that define access to Python, either directly or as a sounding board.  Thanks especially to Wilbram Hazejager (@Wilbram-SAS) who identified potential improvements to an initial, lazy attempt and set me off on a path to find out what really goes on with all those options and environment variables.  Also many thanks to Quan Zhou, Bengt Pederson, Rob Collum, Edoardo Riva, Doug Haigh and others who helped me.  ... View more

Analytics developers require flexible and integrated pipelines where they can access all available tools for their needs.     Sometimes, developers may wish to use methods and functionality from open-source languages such as Python and R.   SAS Viya provides access to these languages through its integration with open source and specifically, in SAS Studio, through procedures like Proc Python.     A challenge is that Python and SAS compute engines operate in their separate environments.  Data needs to be transferred among those environments in a seamless manner in order to take full advantage of integration.   A new contribution - the Python - Load Objects to SAS Custom Step  helps facilitate this data exchange.     To illustrate, once your Python program has done its job, you can transfer desired data objects to a SAS Viya in-memory environment (or the SAS Programming Runtime Environment (also known as SPRE)) for accessing specific functionality or better performance.  At the same time, you can easily free up memory taken up by these objects within Python.         An important note:  this step may be new, but similar capability has existed for a while in the form of the SAS object in Proc Python.  This custom step extends such functionality.  Those who are familiar with the SAS object and the SAS.sd2df (SAS dataset to Data Frame) method are free to continue using them (and it's also used within this Custom Step).  The additional benefits provided by this custom step are:   1. It provides a low-code wrapper around the data exchange process and makes it more transparent instead of buried in code.   2. Provides additional options for more Python data objects beyond pandas data frames, such as single objects (strings and integers), lists, and dictionary objects.   3. Promotes good memory and object management by deleting the Python object after transfer and running garbage collection on the same   Those who are new to the paradigm of programming with SAS and Python in a combined fashion will find this step a useful aid in development of their programs.     Access and Use   This custom step is part of the  SAS Studio Custom Steps GitHub repository,  a collection of low-code components providing a productive and enjoyable developer experience.  These steps provide a user interface for entering parameters, abstraction and enable code reusability for many analytics tasks and programs.   Access the "Python - Load Objects to SAS" step from:   Link to the repository folder: Python - Load Objects to SAS Link to the README: README       To use this within SAS Studio within a SAS Viya environment, a recommendation is to follow instructions to upload a selected custom step to SAS Viya.  Another alternative is to make use of Git integration functionality already available in SAS Studio.  Clone the SAS Studio Custom Steps GitHub repository and make a copy of required custom steps in your SAS Content folders.  Refer this post for some useful tips.      Application   The most common scenario where developers are expected to use this step would be to transfer Pandas data frames to a corresponding SAS table (either a sas7bdat dataset or an in-memory table in SAS Cloud Analytics Services (CAS)).  Pandas data frames are one of the most commonly used Python data structures  in the area of data science, and analytics practitioners may use them to carry out transformations such as calculating a new column, transforming columns and reshaping data inside Python.     As mentioned earlier, a built-in SAS.df2sd method exists in Proc Python, which is meant for transferring data frames to target SAS tables. The SAS object has been created for use within a SPRE environment (also known as SAS compute), but can also be used for CAS table targets.           When CAS targets are specified, there's a dependency that a CAS session should exist prior to the SAS callback object's execution, something which all analysts may not be aware of.   For this purpose, the custom step offers an alternative to the SAS.sd2df method for CAS targets, making use of the Python swat package to transfer the dataset from Pandas to a CAS table.  Some Python coders may already be familiar with the swat package as a means of running CAS actions from Python, and may choose the custom step for this purpose.     Garbage Collection   After a handoff transferring data from Python to SAS, the pandas data frame continues to reside in memory and in the namespace of the Python environment.  A reasonable expectation is that in most cases the data goes through further transformations in SAS anyways, and so the pandas data frame may no longer be needed.  However, in Python, deleting the data frame only removes the link between the object's name (the data frame in this case) and the data it points to.  To actually free up memory, a process called garbage collection is required, which operates under some constraints and has to be explicitly coded by the developer.  To make this convenient, this custom step provides an option to remove the data frame and perform garbage collection after the transfer is executed.  This helps keep memory lean.         The "Quick Promote"   Some flows may perform the entire analytics process in Python entirely, and use a CAS table only as a final destination for visualisation purposes, for example in SAS Visual Analytics (VA).  For such purposes, this custom step also provides an option where users can promote the transferred table to global scope in CAS.  This makes the table accessible from Visual Analytics where it can be used within a report.       Other Python Objects   A bit of trivia : did you know that what's commonly referred to as a variable is called either an object or reference in Python?  There are some discussions on the net around this (and interestingly, some are related to the constraints around garbage collection mentioned earlier).   In any event, this custom step enables you to transfer other objects (i.e. not data frames) to corresponding SAS objects.  These other common object types are:   Pandas dataframes can be transferred to either CAS tables or SAS datasets - we've already covered this. Standard Python objects (int, str etc.) can be transferred to SAS macro variables Lists (array-like data structures) can be transferred to  CAS tables or SAS datasets (with a user-specified name serving as the column name for the list) Python Dict objects which resemble JSON, can be transferred to CAS tables or SAS datasets, using pandas data frames as an intermediary medium.   All the above options are available in the step; feel free to play with them.       Have fun with the "Load Objects to SAS" custom step and I hope it helps you with your open source integration initiatives.  Feel free to get in touch with any thoughts or questions. ... View more

Text data varies in structure, size and content.  Some documents may be short and brief (responses to pointed questions in a survey), while others may tend to be longer and address multiple areas of interest (such as, for example, the review you post after spending the night at an inexpensive rat-infested motel with a window overlooking the sea).   Natural Language Processing (NLP) applications tend to analyse documents in their entirety.  In certain cases, however, analysis at a more granular level, such as at the sentence or paragraph-level, may be considered because: 1. It enhances the quality of analysis by enabling more granular analysis and localising context in some situations. 2. In some other situations, it may contribute towards more efficient processing by allowing opportunities to remove noise and reduce size of individual payload processed against a set of rules. A recent open-source contribution, the NLP - Sentence Splitter SAS Studio Custom Step helps data scientists and data engineers split text observations into constituent sentences while retaining identifiers and other metadata.  This is an easy to use pre-processing component which can be applied prior to running NLP.   This is part of the SAS Studio Custom Steps GitHub repository,  a collection of low-code components providing a productive and enjoyable developer experience.  These steps provide a user interface for entering parameters, abstraction and enable code reusability for many analytics tasks and programs.     Link to the repository folder: NLP - Sentence Splitter Link to the README: README     Access & Use   We first start with the question of accessing these steps from within a SAS Viya environment.  A recommendation is to follow instructions to upload a selected custom step to SAS Viya.  Another alternative is to make use of Git integration functionality already available in SAS Studio.  Clone the SAS Studio Custom Steps GitHub repository and make a copy of required custom steps in your SAS Content folders.  Refer this post for some useful tips.      Using this Custom Step is easy.  Referring to the README, you need:   1.   A table loaded to SAS Cloud Analytics Services (CAS) 2. A column containing text (which may comprise one or more sentences) 3.  A column to be used as a document ID   Upon connecting the input table, assigning the required parameters and specifying an output table, you'd notice the following: 1. The output table will now contain a column called _match_text_.  This column contains sentences as separate observations.   2. Each sentence is identified by an ID variable, the _sentence_id_.  Note that this sentence ID is within the context of the original document,  i.e. Doc 1 will contain sentence IDs of 1,2,3... n (for the number of sentences within) and Doc 2 will also contain 1,2,3... k sentences.     3. To ensure a unique ID for each combination of sentence and document ID, a new ID column called Obs_ID concatenates the Document ID with the Sentence ID (with some padding applied).   4. Individual offsets (_start_ and _end_) denoting where sentences start and end are also provided. An Application Let's now consider a quick application showing the benefit of sentence-level analysis: feature-level sentiment!  Consider this delightful review of an establishment I have had the honour of recently staying at (with their name changed since they don't like fame, naturally):   "I felt wonderful when I noticed the pretty facade of the Jolly Rodent motel. The kindly lady at the counter was gracious enough to let us know we were early, but she would still make a room ready in five minutes. Passing through the courtyard, I admired the ornate water fountain in the middle of a floral garden. Alas! The scene proves completely different when I took in our room. Not that there was much to take in, it seemed to end right where it began! Gritting my teeth and reassuring myself that a bathroom door located next to the cooking range was a novelty, not an hazard, I tried to freshen up. However, the moldy nature of the bathroom and the rust stains on the basin freaked me out. The restaurant food was middling and insipid, and the rude service of the waiters made us wish we were out of there as soon as possible."   Note that I've colour-coded the passage above as per differing levels of sentiment (green indicates positive sentiment, red indicates negative, and the brown is somewhat negative to neutral).  On the whole, upon reading the entire review, it might seem that the review expresses a negative sentiment in general.  But this isn't really fair to the proprietors of the Jolly Rodent, who should be complimented for their beautiful building, front desk service and water fountain.  This is an ideal opportunity for the Sentence Splitter to uncover insights that might have otherwise been obfuscated.  Another benefit is that the smaller text sentences may provide efficiency benefits by allowing developers to weed out noise prior to analytics.  Finally, sentence-level analysis helps support feature-level sentiment analysis or allows for a categorisation or inference to be extracted from a smaller, localised context.     Having run the Sentence Splitter on a table containing the above text, we can then apply an NLP task (such as sentiment analysis) on individual sentences and obtain the following:     Notice how the Sentence Splitter has now enabled individual (positive) sentences to stand out on their own from within an overall negative review?  This use case can be extended and modified for Feature - Sentiment association,  categorisation, progression of sentiment and other applications.    Have fun using the NLP - Sentence Splitter step.  Feel free to get in touch in case of any questions or comments.     ... View more

  Modernization of analytics platforms requires focus on costs and higher efficiency.   Workload Management, the SAS Viya solution to handle many, intensive compute workloads efficiently, has been generally available as an add-on to SAS Viya since Nov 2021.    Two recent developments bring renewed focus upon Workload Management:   It’s now more easily accessible!  From monthly stable 2023.08 onwards, Workload Management is provided out of the box with the majority of SAS Viya offerings.  You only need to enable and configure the same. Configuration now enables automated scaling of compute nodes to accommodate workloads of varied profile! This provides multiple benefits.  For one, automation can quickly address current demand. More significantly, administrators can differentiate resources to suit the type of workload being submitted.   The documentation on how to administer autoscaling policies is pretty straightforward and can be found here.  This article demonstrates how we configured an example deployment for autoscaling and were able to execute workloads using the right resource level and type.    Infrastructure   We’ve based our example on Azure cloud resources, but configuration and setup follows a similar pattern across providers.  When considering infrastructure, we made use of the GitHub Viya 4 Infrastructure-as-Code (IAC) repository for Azure.  In this, we can specify our desired infrastructure which is used by an automation tool (terraform) to interact with the cloud provider and make such ready.  Here’s the topology of SAS Compute nodes we took into account (note that since Workload Management is currently concerned with Compute nodes only, we have omitted information on other node pools, network and storage, but those also have to be factored in).      Table 1: Topography of Compute Nodes      Node Pool Name  Purpose  Machine Type  Min – Max Range  Labels  Compute  For Interactive users (SAS Studio and similar)  Standard_E4bds_v5  4 vCPUs, 32GiB RAM, 150 GiB disk space  1 - 1   wlm/nodeType=”interactive”  Combatsm  Small SAS jobs submitted through batch    Standard_E4bds_v5  4 vCPUs, 32GiB RAM, 150 GiB disk space  0 – 8   wlm/nodeType=”batchsmall”  Combatmd  Medium SAS jobs submitted through batch  Standard_E8bds_v5  8vCPUs, 64GiB RAM, 300 GiB disk space  0 - 2  wlm/nodeType=”batchmed”  Combatlg  Large SAS jobs submitted through batch    Standard_E16bds_v5  16 vCPUs, 128GiB RAM, 600 GiB disk space   0 - 1  wlm/nodeType=”batchlarge”  For All Node Pools  workload.sas.com/class=”compute”  launcher.sas.com/prepullImage=”sas-programming-environment”      Some salient points:    As already stated, this is only for SAS Compute node pools.  SAS Compute node pools are designated to handle programs which run in either a compute server or batch server session.  Mostly SAS programs which usually run on SAS datasets, they may also cover programs which make calls to other compute engines such as SAS Cloud Analytics Services (CAS) or Python or R (if Python or R has been configured).   All nodes forming part of the above node pools need to be labelled as workload.sas.com/class=”compute”.  Only nodes labelled as such will consider Compute workloads for processing.  The above is opinionated, meaning we, as administrators, decided to provision the above configuration for purposes of this example.  How do organizations decide on the type of node pools they can harness? Some may choose to go with just one, while some others may have a wider range at their disposal.  This choice is based on their current profile of SAS workloads and many other factors (including cost).  One tool which can help your organization make this decision is Ecosystem Diagnostics, described further in this article.  Notice a majority of the planned node pools start with a minimum of 0 nodes.  This signals that even were we to provision a variety of node pools, autoscaling enables a scale up from zero and we wouldn’t need to pay for compute resources unless they are actually used.    At the same time, notice the outlier (“Compute”, for Interactive purposes) node pool which has a minimum of 1.  This is done on purpose, because interactive users appreciate a compute server which is always on due to the nature of interactive workloads.  Simply put, in this day and age, you don’t want interactive users staring at spinning wheels or cranking up a node to make it start.  You have the flexibility to keep a warm node to serve a subset of users, maybe with a small machine in order to keep cloud costs low.  Don’t forget to add the additional label:  launcher.sas.com/prepullImage=”sas-programming-environment” for all nodes.  Saves you a lot of angst.      Configuration   This is the fun part.  Given provisioned infrastructure, let’s look at how to configure Workload Management & optimize usage as per needs.    You can configure Workload Management through an plugin called Workload Orchestrator (WLO) in the SAS Environment Manager application.  Administrators use WLO to implement decisions regarding the appropriate resource to run a workload.  For users, this is a great resource to monitor the status of jobs.      The process of configuration is greatly eased when you consider the entire configuration as a single JSON containing all the required details.  In the configuration page of WLO, simply click on “Import”, import the sample configuration provided here, make required changes, and you are set.  Conversely, you can also export the configuration at any time to make use of the same in a different environment later.    Of course, even more fun is actually looking at the individual components making up the configuration.  The official documentation on configuring Workload Orchestrator provides more details.  Here, we’ll focus on tasks which support the following basic flow of events.     Figure 1: Workload Execution - user flow      A lot going on in the picture above, therefore let’s attempt to summarize:  Users require execution of their workloads (SAS programs).    They submit workloads through interfaces like SAS Studio (which contain an element of interactivity) or via batch jobs from the command line.    Every submission is flagged with a context, which indicates the broad set of parameters under which this job will run.  The context could be either a Compute context or a batch context.  This context is wired to run in a SAS Workload Orchestrator queue. Queues are defined in Workload Orchestrator to govern, among other things, where and when the jobs may be executed.  The queue is configured to request that the job be run on a host type where such is defined.  Host types are configured with host properties that specify the labels (from the table in Infrastructure, above) which identify candidate nodes to run the workload on.    The host types are also flagged as being enabled for autoscaling or not.  Given a request for a job to run on a host type, Workload Manager makes a request for an available node. If the node is available, the requested session (either sas-compute or sas-batch) is started on that node to execute the job.    If a node is not available, but the autoscaling flag is enabled on that host type, then Workload Manager works along with the Kubernetes cluster-autoscaler to signal a need for a node to execute the session on.  The cluster-autoscaler responds to this signal by requesting a node from the cluster, which is then spun up to execute the job.   There are a number of conditions which determine whether a node is available or not, which is explained in detail in the following documentation link.    Experience   Let’s now actually watch things in action! In an initial state, with everybody goofing off - er, let’s just say it’s the start of the day – the following is the state of the system as represented by SAS Workload Orchestrator.    Figure 2: Dashboard of SAS Workload Orchestrator      Figure 2 is the dashboard view of Workload Orchestrator.  On the left hand side, there is information about the version, license expiration, build date and GUI build date.  The top half view lists Queue Status.  In our case, there are four queue status tiles representing what’s configured - default, batch-large-queue, batch-small-queue, batch-medium queue.  From the queue status, you can see all the queues are open and active.  No closed queue.  All have 0 jobs pending.  The lower half view is the Host Status.  There’s one server shown as  Open and in OK status.      Which can also be picturized as follows:    Figure 3: Initial State      Whoa! – you may chortle in righteous indignation.  How come there’s a machine switched on if there’s no work?  Well, that’s the warm node kept alive for interactive users.  It’s a small price you pay to have nodes available for users who may come back to their desks and start coding. Luckily, thanks to Workload management, you can keep this lean by provisioning only a small machine (minimum cores and CPUs) to satisfy this usage pattern and keep cloud costs low.     Let’s now take up a case when work actually starts to happen.      Figure 4: Screenshot of sas-viya CLI      Figure 4 demonstrates submitting a program using the Command Line Interface.  The Runme.sas program is submitted using the default (batch) context. The default context maps to the batch-small-queue. In Figure 3, there is one job pending in the batch-small-queue.  Since autoscaling is enabled, the job is kept pending until the cluster auto-scaler requests a node available, and that node becomes available and ready to be used.  As mentioned above, the cluster auto-scaler obtains this signal (to auto-scale) from Workload Management, based on the configuration provided.     Figure 5: Updated Dashboard View      Figure 5 shows a change in state in the updated Dashboard where the program RunMe.sas is in a pending state in the batch-small-queue.  The job will stay in the pending state until the new node is available.      Figure 6: Updated Dashboard View      Figure 6 shows a change in state in the updated Dashboard where the program RunMe.sas is now running in the batch-small-queue and a new node is up.        Figure 7: Calling README.sas through the Command Line Interface    Figure 7 displays the job completed and Figure 8 now displays the current state of the Dashboard.  The job completed.  However, the new compute node is still active showing Open-Ok, looking for any other jobs before it scales down. After lapse of a certain time period (governed by configuration), if the node continues to be idle, it is picked up by Kubernetes for termination. This link describes the conditions which trigger a scale-down of nodes.    Figure 8: View of Workload Orchestrator after program run      Now it is time to really have fun.  Jobs are being submitted to the batch-large-queue, batch-medium-queue and default queues in Figure 7.    Figure 9: View Queues tab      The view of the queues tab shows 1 job is running on the batch-small-queue. 1 job is pending in the batch-large-queue and 1 job is batch-medium-queue. Why are they pending?  Remember from Figure 8, since we already ran a job from the batch-small-queue a node was up and waiting for more requests.  Now, we are waiting for nodes from the batch-medium context and batch-large context to fire up and enter a state of readiness, which leads to an Open-OK against the host.        Figure 10: New WLO view      Figure 10 shows the dashboard view again.  We focus on the Host status where we can see the interactive host waiting on interactive jobs.  The hosts are associated with the batch-small-queue is active since we have a job running.  Figure 11 shows another host that scale up running the job from the batch-medium-queue.  Figure 12 displays the batch-large-queue is running a job and the host associated with the server is Open and Ok.       Figure 11: Dashboard View with batch-medium-host available        Figure 12: Dashboard View with batch-large-host available      The above (Figure 12) is the state when all available Compute node types (as detailed in the infrastructure section) are utilized.  As workloads increase (based on business needs) , the extent to which these node types are accessed will vary, highlighting the ability to differentiate resources as per the needs of the workload.  Pictorially, Figure 12 can also be represented as follows:      Figure 13: Workload Management in a busy state        Figure 14: Hosts tab      Figure 14 displays the hosts tab.  The information on the Dashboard and the host tab are the same information but the information is presented in a different view.    With the completion of all the jobs running, the hosts have scaled down and we are left with the Interactive Host waiting for interactive jobs in Figure 15.       Figure 15: WLO rests    In summary    As evidenced by SAS Viya’s move to cloud-based architecture, modernization of analytics platforms focusses on costs and higher efficiency. Workload Management, through its recent autoscaling capabilities and other elements, facilitates the following:    Reduced idle capacity   Differentiated & right-sized resources per workload  Automated decision making on resources, triggered by user activity  Reduced pending jobs and higher queue utilization  Centralized administrative activity and interfaces (less overlap between Kubernetes & SAS Viya administration control)    Drop  us  an email with any additional questions.      References    About Azure Virtual Machines: https://learn.microsoft.com/en-us/azure/virtual-machines/  SAS Ecosystem Diagnostics: https://communities.sas.com/t5/Ask-the-Expert/Why-Do-I-Need-SAS-Enterprise-Session-Monitor-and-Ecosystem/ta-p/854162  Documentation related to Workload Management and cluster autoscaler: https://go.documentation.sas.com/doc/en/sasadmincdc/default/wrkldmgmt/n1s5vpyfr4sq3zn1i1dp1aotpzka.htm   ... View more

Beyond a certain point, programming language shouldn't matter.   Analytics developers appreciate unified platforms which accommodate different programming environments and languages, be they SAS, Python, R or any other.   Access to multiple programming languages also requires that we consider seamless interoperability.     SAS Studio, an application within SAS Viya, offers powerful data engineering and analytics through low-code and programming components.  SAS Studio already provides easy interface to Python through a Python editor and the Proc Python procedure.  However, at present, there doesn't exist similar easy access to R.   This article describes R Runner, a SAS Studio Custom Step, which helps you program in R from SAS Studio on SAS Viya.     Teams who code in both SAS and R can now develop more integrated analytics. This especially benefits certain industries where we've noticed a lot of interest in using SAS and R together, such as Pharma, Healthcare & Life Sciences, pockets of the insurance industry, and the public sector.   Watch this video for a quick description of what you can do with R Runner.       Access R Runner   SAS Studio Custom Steps are low-code components which abstract complex programming logic into an easily consumable package, used across programs and sessions in a repeatable manner.   Access R Runner from this folder on the SAS Studio Custom Steps GitHub repository.  Also, here's a direct link to the README.  Note and follow instructions within to import the custom step into a SAS Viya environment.       Use R Runner   R Runner offers a simple, no-nonsense capability: run R programs from a  SAS Studio session.  This can be done standalone, or as part of a larger process, typically designed as a SAS Studio Flow.  Here are some simple building blocks to help illustrate.      Provide input data    Most analytics require input data. Attach input data to R Runner through an input table port.  Note that if you are running the step within a flow, you may not notice this the first time.  Right click on the step and select "Add input port" for the "inputtable" port.  If running the step standalone, select an input table as directed in "Provide an input table".       Here's what happens.  Given an attached input table, upon execution, proc python converts this table to a Pandas data frame using the SAS callback method under the covers.  Then, a Python package called rpy2 is used to convert this Pandas data frame to an R frame, the type of tabular data structure that R processes.  There's no need for the user to provide code for this conversion.  Once this conversion is complete, user-submitted R code will be taken up for execution.  The data frame uploaded will henceforth be known as "r_input_table" inside the R environment.   Run an R snippet   Users have two options to submit code to the step for execution.  Sometimes, you may wish to run a short set of commands in R.  These could be simple tasks such as summarising a data frame or creating a frequency table.  Users can provide such short snippets / commands inside the text area on the custom step.  The text area is limited to contain a maximum of 32768 characters. Users are encouraged to attach an R program for longer programs.         Here's what happens. R commands submitted inside the text area get written to a temporary file which is then passed on to the r object within rpy2.robjects.  Refer here for an example provided in the rpy2 documentation which shows the code executed behind the scenes.  The benefit to the user is that similar code is baked into this custom step and therefore R programs are passed over to the R interpreter seamlessly using the rpy2 package.     In the interest of full transparency, note the text area is a component of the SAS Studio Custom Steps framework and therefore should not be considered as an editor capable of interpreting R code.  In short, do not expect features like syntax check, automatic indenting or any of the other magic you may encounter in editors like Visual Studio Code or RStudio, among others.     Refer an R program   Not all R programs are short enough to be submitted directly to the text area described above.  For longer, more involved code that you wish to lift and shift to SAS Viya,  simply attach your R code to the step for execution.  This makes it convenient to quickly use existing R codebase and minimise scope for changes.       Here's what happens.  When you provide an R file reference, R Runner checks the location of the file, and then refers it directly within the r object of rpy2.robjects.  This ensures direct access to the code as-is without any intermediate processing.     The second advantage of referring an R program: other conveniences offered by SAS Studio such as Git integration allows users to refer R programs located in a local folder linked to a Git repository.  Upstream changes in the R codebase, once managed with Git, could seamlessly sync a local folder and your process (which may use this custom step with other SAS Studio objects) automatically picks up the same!   Users are advised to refer to R programs located in the filesystem (disk storage attached to the Viya environment), and not files located in SAS Content (the Infrastructure Data Server).  The custom step has been built to work with filesystem content so that program artefacts can be easily transferred (as well as take advantage of Git).     Export output data   Finally, once your R program has finished, it's time to access any output data generated.  The output data in R could be in the form of an R variable or an R data frame (unless the program explicitly writes results out to a file).  Users might like to use this output data in downstream processes, which may involve other SAS programs (one of the advantages of running R under a unified platform).  This custom step makes it easy to export output data frames from the R process to a SAS dataset for downstream processing. Users can specify the name of the desired output data frame and provide an output dataset to hold the resultant data.     Here's what happens.  This part of the process is in some ways the reverse of what occurs when ingesting input data. First, the specified R data frame is transferred to a Pandas data frame using the rpy2 package.  This Pandas data frame gets converted to the desired SAS dataset using proc python and the SAS callback method.  Once the data is output, users are free to interact with it any way they like (using SAS or Python programs).  At the same time, if they wish to continue working on the R data frame, they can simply dispense with creating an output dataset and instead call the same R global environment variable (i.e. the data frame name) in a subsequent R Runner step.  The same R session is maintained as long as a valid Python session (with the rpy2 object) is in place.   An eye to the future   We've released the first version of R Runner and focussed on delivering the essentials - i.e.  ensure R code can be executed, data can be sent to R, and data output from R, in the service of an overall larger integrated process in SAS Studio.  We are actively considering and developing some exciting future improvements, including an easy outlet for graphics (plotting images and charts), better redirection of output wherever feasible and more transparent logging.  We welcome your suggestions for enhancement and improvements.  Please drop us an email by clicking here.  Have fun with R Runner. ... View more

Ever played with model trains as a kid?  I have (with a neighbour's set, leading to quite a few tracks broken as a result, but that's another story), and in some of the more expensive sets, we can use switches to move the train along a different track.  Fascinating. Sigh.  Owing to the many broken parts mentioned earlier, I never got to operate railway switches first-hand.  Maybe that motivated this similar approach which operates on SAS Studio Custom Steps, instead. SAS Studio Custom Steps are useful low-code components which help you encapsulate and execute SAS and Python programs, either standalone or within a SAS Studio Flow.   A SAS Studio Flow follows a linear process but does not provide developers much flexibility in orchestrating conditional logic, unless this logic is embedded within individual programs. While developing a flow, I faced a scenario where I needed to run a particular step as a matter of routine, but not when I faced a special condition (based on my input data characteristics).  Indeed, I might have carried out redundant (and time-consuming and ineffective) work if I had continued to run the step, which could prove costly in large data scenarios. Therefore, I devised a mechanism embedded into my custom step to dynamically control the execution (or non-execution) of a custom step.  This is carried out through a trigger variable which can be changed during run-time.  Let's look at a simple example and also understand how replicable this approach is.         A simple example   Let's keep this relatable through a very simple example.  To begin with, follow along by importing this SAS Studio Flow, which uses two dummy datasets.  The GitHub repository contains instructions to import this artefact. Let's suppose you've received a dataset for analysis, over which you don't have much control (most publicly available data falls under this realm).  You desire that this dataset conform to certain standards in order to ensure high quality analysis, and included among those standards is the presence of a unique identifier. Now, it's highly probable that your dataset already contains a column that might purport to be a unique identifier (say, a complaint ID), but it's tough to take this at face value.  For example, what if some complaints had follow-up interactions manifested as a separate record (with the same ID)?  You might consider taking the easy way out and creating a new column with a new unique ID, but that's additional processing which you may like to avoid as much as possible. In our example flow, we first create two dummy datasets. One of these have a non-unique complaint ID, and the other contains all unique complaint IDs.  My objective is to first validate if these IDs are indeed unique, and, only if they aren't, I'll go ahead and create a new unique ID variable. Validating if an identifier is indeed unique, for a SAS Cloud Analytics Services (CAS) table, is now possible thanks to the CAS - Validate Unique ID custom step, available through this link.  Similarly, generating a unique ID is possible through the CAS - Generate Unique ID custom step.  It is this step that I have now enhanced through a macro variable, which I call a trigger variable.  Take a look at the tab which explains this variable, which is self-explanatory.       Now, let's consider one of the swimlanes in our SAS Studio Flow.  A swimlane executes linked nodes (SAS programs, Python programs and steps, including custom steps) from left to right, then top to bottom.  In the normal scheme of operations, the "Generate Unique ID" in the bottom portion of the lane would have executed irrespective of whether there were all unique IDs or not.  With the run-time control, however, I carry out a check after validating the unique ID, and change the trigger variable to 0, therefore "disabling" the running of the custom step.  It still exists in the flow, but the main execution code within the custom step has been dynamically set to not execute.           The results can be viewed in the log when we use an input table which has all unique IDs.  In such a case, the "Generate Unique ID" step was not required to execute, and it did not. A message in the log indicates such.         In summary We've successfully demonstrated how it's possible to control the execution of a custom step dynamically within a flow during run-time.  This type of conditional processing can be extended to other SAS Studio Custom Steps, based on need.  Is it really required for all Custom Steps, though?  The answer depends on your business problem.  If you are frequently in situations where the code execution context does not require  a step to run, then it's worth adding this run-time component. Have fun trying out the example, and feel free to email in case of any questions.   ... View more

Rules comprising classification and information extraction (concept) models in SAS Visual Text Analytics (on SAS Viya) live a cloistered life.     Natural Language Processing (NLP) developers interact with these rules through Model Studio, a GUI facilitating easy model development without the need for programming.  These rules are persisted inside SAS Viya's solution database as well as the caslib linked with every text analytics project.      At the same time, AI stakeholders demand better understanding and transparency on the logic & machinations of analytics models.   Rule configuration tables provide rich metadata facilitating the same.  Even metadata deserves its day out in the sun, sometimes.     Rule configurations help explain model logic to business stakeholders, promote better model governance, assist in customising models, and enable better consumption and understanding through rich visualisation.     Let's look at a recent GitHub contribution which provides a SAS Studio Custom Step to extract NLP rule configurations.  SAS Studio Custom Steps are low-code interfaces used either standalone or within an analytics pipeline (a SAS program or a SAS Studio Flow) to perform a task in an extremely convenient manner.     Here's the README for the custom step.  In addition, this link takes you to the project folder from where you can download the custom step and start using the same.   Access the Custom Step   Let's first make this step available to a SAS Viya environment.  A simple approach is to follow instructions to upload a selected custom step to SAS Viya.  Alternatively, make use of Git integration functionality already available in SAS Studio.  Clone the SAS Studio Custom Steps GitHub repository and make a copy of required custom steps in your SAS Content folders.  The below animated GIF shows you how.  In this case, the folder to move / copy is "NLP - Extract Rule Configuration".         Use the Custom Step   There are three primary applications of this custom step, described in the following YouTube video.  The custom step can be used to either generate a list of rule configurations within a project, extract all rule configurations as specified in an input list, or extract a specific rule configuration table.  Watch the YouTube video to learn more!       What can you do next?   Once extracted, the rule configuration can be applied to a number of downstream activities.  Here are three examples.   1. Identify changes in rules   Rule-based systems are usually created in collaboration with multiple team members and are subject to a stewardship process.  During model development, the dynamic nature of the current rule configuration necessitates monitoring any incremental changes.  This custom step can be part of a solution to capture changes to a model and monitor the same via a Visual Analytics (or other) dashboard.  Extracted rule configuration tables at different snapshots of time can be used for this comparison and impact assessment.     2. Analyse rules with low accuracy   Some categories may be more or less accurate than others.  This custom step facilitates analysis of rules with low accuracy metrics and identification of avenues for improvement.  Decision makers may also like to understand the logic behind the classification before making critical business decisions.  Accessible rule configuration facilitates such analysis.   3. Surface configuration within governance applications   Registered NLP models in Model Manager are saved in an astore format, which is a binary format focussed on efficient execution of the model against new data.  It's not possible to infer the rules and logic from a binary format.  Therefore, it helps to also maintain a version of the  rule configuration in human readable format within Model Manager.  Once you've extracted the rule configuration table, you would be able to send it via API to Model Manager as a Score Resource and ensure that it's included under the list of governed model assets.   Have fun with the NLP - Extract Rule Configuration custom step.  Feel free to email in case of any questions or comments.   Bonus: try it out An example SAS Studio Flow which makes use of the above custom step (for all three options it offers) is available here.  Note, of course, that you would require a Viya 4 environment which contains Visual Text Analytics and SAS Studio Engineer in order to try this out.  Also, please create a simple VTA project of your own which contains some models for which you can extract rule configurations.   Related Also, refer this blog for more details on a run-time control for custom steps, which has now been incorporated into this step.   ... View more

Interfaces matter.  User and Developer Experiences matter.   That state-of-the-art robot vacuum cleaner (or home voice assistant device, or self-driving car) is much less enjoyable if you can only  interact with them using complex programming interfaces.  For the last two years,  SAS Viya customers have had access to low-code, accessible custom steps within SAS Studio, which wrap and abstract complex code and provide developers faster time to value.   Recent text classification actions, based on deep learning (BERT) architecture, have augmented the hybrid NLP (Natural Language Processing) approach that SAS advocates.  A hybrid NLP approach provides you better chances to design accurate and performant models, and incorporates machine learning (of which deep learning forms a part) in addition to rules.  BERT (Bidirectional Encoder Representations from Transformers), a deep learning architecture based on transformers, is well suited for analysing labelled, sequential input data (such as text) with a high degree of accuracy.  At this time, SAS Visual Text Analytics on SAS Viya offers these actions only through programming interfaces (i.e. code) such as the CAS language (CASL), Python, R & Lua,  which may limit the range of potential analytics users who can benefit from these actions.   Enter the SAS Studio Custom Steps GitHub repository.  Provided as a community contribution, these custom steps hugely simplify the whole task of training  and scoring deep learning-based text classification models in little to no time, putting you on the fast track to higher value!   Here are the READMEs and the folder contents for the two custom steps.     README Repository Folder Train a Text Classifier Folder : Train a Text Classifier Score a Text Classifier Folder : Score a Text Classifier     Access the Custom Steps   We first start with the question of accessing these steps from within a SAS Viya environment.  A recommendation is to follow instructions to upload a selected custom step to SAS Viya.  Another alternative is to make use of Git integration functionality already available in SAS Studio. Clone the SAS Studio Custom Steps GitHub repository and make a copy of required custom steps in your SAS Content folders.  The below animated GIF shows you how.  In this case, the folders to move / copy are "NLP - Train Text Classifier" and "NLP - Score Text Classifier".       Train a Text Classifier     Deep learning based classifiers require labelled data.  Identify a dataset which contains, at a minimum, the following two components.  One is, for obvious reasons, a text column which contains the text on which you may like to generate a classifier upon.  Examples include customer reviews, customer complaints, newspaper articles, random Wikipedia pages you have pulled from the internet (because, like me, you may have run out of ideas for data) etc.     The other is a label, (also called a category or a target), which represents a category under which text needs to be classified.   Referring the text examples again, - Customer reviews could be classified under a star rating , or a Like / Dislike flag. - Customer complaints could be classified as per the department / workflow they need to be assigned to. - Newspaper articles could be classified under sections (politics, sports, entertainment, classifieds etc.) or location for easy search and retrieval. - Random Wikipedia articles can be classified as per ..... well, random begets random, so it's likely you don't have a predefined label.  So maybe you may like to manually label these articles (which surely, somebody must have done at some point of time in the past).  This will be a useful way to appreciate the yeoman work done by original data labellers, at any rate :).        Training a classifier is extremely easy.  Connect an input table (refer README for more details) and enter (or change) parameters within the UI.  We've already talked about the text variable and the target variable, but in addition to those, here are other considerations   i) Use a GPU (Graphical Processing Unit) or not?  The choice is yours to make, but in my personal opinion, it's hardly a choice.  If you are one of those lucky people who have access to an environment with GPUs (I exaggerate; they are actually a bit more common nowadays), I would recommend checking this box.  GPUs prove very useful in shortening training time which is appreciated. As experienced data scientists can attest, more training time forces you to take up hobbies such as watching paint dry.  Of course, I'm sympathetic to those who have only CPUs at their disposal, but please be prepared for longer training times before you get a model with decent accuracy.    ii) Hyperparameters : The custom step carries certain default values for the hyperparameters governing the training process, which is convenient for beginners who are planning to try this action for the first time.  These hyper parameters are editable and can be used to configure the training process, which may give you better accuracy than the default.  Here are some of the hyperparameters you may like to play around with.        (a) Chunk size :  the number of tokens which the action breaks the original text column into, for purposes of training.  The default value is 256.  Smaller chunk sizes might mean that you have smaller "chunks" (collection of tokens) which go into the training process, which may make for a faster training process.  But, when you think about it,  you may actually be compromising on accuracy because of a loss of possible context in the chunk.  Therefore, experiment and choose wisely.      (b) Maximum number of epochs : The number of times the training process will take a pass at the training dataset. Consider increasing the epochs in order to provide your process a better chance of fitting a more accurate model.  However, this definitely comes at the cost of time, since there will have to be that many more additional epochs that have to be run through.   In addition, feel free to also change other settings, which may help you control aspects such as memory usage and (to an extent) ensuring similar results.   A convenient feature is that at a minimum, the action expects only a training table as an input table.  You have an option to also provide validation and test datasets, which are always recommended in terms of establishing robust results.  However, if you fail (or forget) to provide either a validation or test table, the custom step doubles up and uses the training table for validation and test purposes.  Additional configuration such as the validationPartitionFraction come into play, in such a case.       At this point, you will obtain a model (located within a CAS table) as output from the trainTextClassifier action.  So far, so good.  If you happen to be satisfy with the results, it's time to go ahead and use this model in a scoring process.     Score a Text Classifier     The nitpicky may rephrase this "score data using a text classifier" which is exactly what the second custom step does.  In this particular case, the input data may contain just the text to be classified, and need not be labelled (given that this is fresh data on which we are carrying out an inference).   The custom step does, however, require the model table (obtained from the step above) to be used as a parameter, since this contains the logic which is executed on fresh data.         Your analytics process now looks like the above diagram.  It's wonderful when you are able to obtain a bird's eye view of these low-code components in one shot, understand and monitor the entire process, instead of having to manually associate pieces of code together.  After specifying the model table and the input table, you specify the text variables, document ID, and are good to write results to an output table.  A special feature accessed from within this custom step is the "Include All Scores" option, which is quite relevant to text classification problems.  Just like Juliet opines in a totally unrelated context, a rose is called by many other names, and (doubtless) smells just as sweet in text classification.  A complaint, for example could be classified as per its problem domain  (such as account-related, transaction-related), but also as per the product (checking account versus savings).  Checking the "Include All Scores" option not only provides you the capability to look at the final prediction, but also at similar high scores which may pertain to different areas, and get classified accordingly.   It also proves useful in cases when (as happens so often nowadays), the text classification acts as an input in a larger model, such as predicting whether the customer will churn or not.     In Summary   It has become much more easier to access Natural Language Processing tasks, especially those which are concerned with deep learning / machine learning.  Low-code analytics components, such as custom steps, have facilitated better design, execution and management of building text classifier models, which were recently introduced capabilities.  This is also a testament to how it's possible to use the unified SAS Viya analytics platform to our advantage in order to ensure easy access.   Have fun with the custom steps to train and score text classifiers, and feel free to drop me an email in case of any questions.   ... View more