During my SAS Innovate 2026 session, I shared six different ways to run Python in SAS Viya. I know, I didn't follow the standard presentation rule of only giving lists in 1, 3, 5 or 10 because apparently any number in between makes people uncomfortable. I just had too much to say in too little time.

This blog series is my chance to dive deeper into each approach than I could during the presentation. Think of it as the Director's Cut. Rumor has it Project Hail Mary was nearly four hours long before they trimmed it down to two and a half. Don't worry – I'm not going to make you read that much. But I am looking forward to that release.

Everyone has their preferred way to develop. And in some cases, a way they're required to develop. I'm not here to tell you which approach is best, because there is no "best." My goal is to show you the options. Yes, I have my favorites. You probably have yours, too. Of the six, you might only want one. Or maybe company policy, infrastructure or security requirements narrow your choices for you. That's okay. You've got options.

I'm starting this series a little differently than I did in the presentation by beginning with SAS Viya Workbench. It's one of my favorite environments for rapid development and experimentation, especially when I want a familiar, high-performance Python workflow that won't make my laptop sound like a Boeing 747 on takeoff.

Part 1 - SAS Viya Workbench

SAS Viya Workbench has a familiar browser-based Python development environment with that laptop experience you know and love, plus powerful compute you can choose on the fly, GPU support, and the governance IT departments expect. Open-source developers want to experiment quickly and with few boundaries. You see a popular package out there on GitHub and you want to see what it’s all about. Maybe you want to build it into your workflow. Maybe you want to iterate with it in dozens of ways. Maybe even break a few things along the way.

SAS Viya Workbench gives you that speed and autonomy without giving up the tools you already know. Here’s how.

It’s your environment

You. Yours. No one else’s.

This is your space to work the way you want to work. Spin it up, shut it down, run out of memory, restart it, use a bigger server, use a smaller server, try new stuff, make another workbench, throw things at the wall and see what sticks. If Technologic by Daft Punk is stuck in your head now, I’m sorry. Or you’re welcome.

Want Python and SAS in VS Code? Done.

VS Code extensions? The marketplace awaits.

Prefer JupyterLab instead? Sure.

Want to see how far you can push it? Ramp up to the biggest server.

Want to see how efficient you can be? Shrink down to the smallest server.

Environment variables? Just open the settings menu and add them.

Virtual environments? Have at it.

Need external storage? Add a volume.

Git? Git ‘er done.

It’s all right here in your browser, and it feels darn near indistinguishable from the desktop tools you already know. Your IT department will appreciate it, too: the entire setup process is covered in this video in just over 9 minutes and is a self-service infrastructure once it’s set up. Configured, customizable for your needs, ready to go, and ready for you to dive in. I seriously love programming like this.

GitHub Copilot at your service

GitHub Copilot is there and ready to help you build. This isn’t some watered-down version of VS Code. This is VS Code the way you expect it in a modern development environment.

Bash away

Have you ever been on a system and wished you had shell access to run some Bash scripts? Or maybe you just want to build a Python virtual environment? Hit Ctrl + Shift + ~ and voilà: your terminal awaits your commands. Want uv to manage your virtual environments? U’ve got it. uv makes dependency management easy and you can use it in SAS Viya Workbench.

Built with Python in mind

There’s a good reason why VS Code, JupyterLab, and Jupyter Notebooks are the three main ways to work with Python in SAS Viya Workbench. VS Code and notebooks are familiar territory for Python programmers. Whether you want to write .py files or iterate cell by cell in a notebook, SAS Viya Workbench gives you familiar development options and the flexibility to switch as you work.

Wait, we’ve talked a lot about Python here. Isn’t it called SAS Viya Workbench? Where is SAS in all this? For starters, it comes with a high-performance SAS environment that includes the latest SAS Viya machine learning algorithms and open data access methods like Parquet and DuckDB. These are all accessible from the pre-installed SAS extension for VS Code. And yes, it does support Enterprise Guide. But that’s just the beginning.

If you’re a pure Python programmer, you probably don’t want to even hear the word PROC.

We know. We get it.

That’s exactly why we built the sasviya package. sasviya is your Pythonic access point to SAS’s algorithms. You may be wondering, “Do I need to learn a whole new package syntax?”

No.

Do you know scikit-learn? Then you know sasviya.ml

Do you know NetworkX? Then you know sasviya.network

Do you know Pillow and OpenCV? Then you know sasviya.cv

Adherence to PEP standards, community standards, and compatibility with popular Python packages are an extraordinarily important part of sasviya. We don’t take this lightly: you’ll see few, if any, SAS language elements in these packages. That’s how committed we are. After all, the incredible engineers here at SAS are programmers, too. They get it.

Why would you want to use these models over others? Let’s take a look.

High-performance SAS algorithms in a way you understand

Back when I was a data scientist, I built a lot of machine learning and AI models with SAS. From forecasting to gradient boosting to deep neural networks, I worked with massive amounts of data without needing to think much about it. SAS algorithms and SAS itself as an engine are both really good at dealing with complex data that’s hard to compute.

I wrote about this in one of my blogs, Boost ML Accuracy with hyperparameter tuning, where I took an 11M x 21 dataset and ran it through the autotuning gamut on a modest 16-core, 64 GB RAM server with sasviya.ml.tree.GradientBoostingClassifier. In fact, I gave it a try with five separate default models, all of which ran without issue.

I initially tried it with scikit-learn, and it took nearly 45 minutes to complete one model. Switching over to sasviya.ml was as easy as changing my import statement:

from sasviya.ml.tree import GradientBoostingClassifier
 
model = GradientBoostingClassifier(
    n_bins=255,
    n_estimators=100,
    max_depth=3,
    min_samples_leaf=20,
    learning_rate=0.1,
    random_state=42
)

If you’ve used scikit-learn, that should look very familiar to you. sasviya.ml models also come with a few other nice bonuses beyond just the basics:

• They accept Pandas DataFrames, Polars DataFrames, PyArrow tables, and DuckDB queries natively without any internal copying
• No one-hot encoding necessary: give it categories and sasviya just handles it
• Generate pre-built, customized plots for supported models with customize_results()
• Get model details through describe() that you would otherwise need to calculate yourself
• Pickle a model or export it as an Analytic Store (ASTORE) to easily run in enterprise Viya
• Some models, such as LogisticRegression, produce results that match the equivalent SAS PROC with default settings, making validation and comparison easier

If you’re a SAS programmer, you might be looking at this and thinking “Well yeah, I do this all the time. Those are some of my favorite parts of SAS: the speed, the built-in one-hot encoding, the diagnostics, the graphs, the model transportability, and the consistency.”

That’s precisely the idea: bring the best parts of SAS to Python. And we’re continuing to do that today thanks to your feedback.

Wrapping this first one up

There’s a lot to love about SAS Viya Workbench if you’re a Python programmer, and even more to love if you know SAS, too. It gives you a flexible place to build, test, and iterate without being constrained by the thin little rectangle whirring away on your desk. And if you work with SAS programmers, you’ll like the ease of being able to share code and models between each other. These days, I find myself reaching for SAS Viya Workbench for Python and SAS programming more often than my own laptop. Sometimes I need more compute. Other times I want to try something crazy that could make my computer come to a screeching halt or bring down a shared dev box. I always have the latest and greatest algorithms from SAS, and I don’t need to reinstall anything to get them. It’s simply just there.

Links

• SAS Innovate 2026 Presentation – Python Your Way: 6 Ways to Run Python in SAS Viya
• SAS Documentation – Python and SAS Integrations
• SAS Documentation – About the sasviya Package
• SAS Documentation – Access Data
• SAS Documentation – Advanced Analytics
• SAS Viya Workbench Examples
• SAS Viya Workbench on the Azure Marketplace
• SAS Viya Workbench on the AWS Marketplace
• Looking for more ready-to-go SAS tools on the Azure Marketplace?
  Check out SAS Data Maker and its wide range of data generation methods

Python your way: 6 ways to run Python in SAS Viya was published on SAS Users.

Migration is often described in technical terms: workloads moved, systems retired, data transferred, users onboarded. Those measures matter. But they do not tell the whole story. The real value of modernization shows up when organizations use migration to rethink how they work, scale and prepare for what comes next.

That idea comes through clearly in two SAS customer stories: Posten Bring, a Nordic postal and logistics company with nearly 400 years of history, and Regeneron, a leading life sciences company building a modern statistical computing environment. Their industries, operating models and modernization paths are different. Yet both arrived at the same conclusion: successful migration requires strategy, discipline, user trust, a clear reason to change and a strong partnership with SAS.

Posten Bring: Move the organization forward, not just the systems

For Posten Bring, modernization was a continuation of a much longer story of adaptation. Founded in 1647, the company has reinvented itself many times. In recent decades, digitalization reduced mail volumes by about 80%, while logistics became a larger part of the business. Data became central to how Posten Bring improved operations, increased production efficiency and competed in a changing market.

SAS has supported Posten Bring since 1999, but the company’s SAS 9.4 on-premises environment had reached its limits. Capacity constraints limited real-time capabilities, weaker API support and rising demand from users who needed faster access to better data made modernization necessary. As the Posten Bring team put it, SAS 9.4 had helped get them there, but it could not take them further. Their next step was to modernize with SAS Viya for streaming data, integrated analytics, a fast modern database, and scalable cloud with SAS Managed Cloud Services.

The work was complex. Posten Bring moved 20 years of legacy code, thousands of ETL jobs across 35 BI solutions, hundreds of SAS Enterprise Guide projects, and tens of terabytes of data from on-premises systems to SAS® Viya® with SAS Managed Cloud Services and SAS SpeedyStore. And the technical work was only part of it. The team also had to upskill hundreds of users and change how people worked so they could take advantage of the new Viya platform.

Along the way, the team worked through data migration challenges, integrations, network and firewall requirements, character and collation issues and the practical question of what should move. The project also showed the strength of the SAS partnership. When serious issues surfaced, the teams worked together to solve them and adapt the software to support Posten Bring’s business needs.

Several lessons extended well beyond the migration itself:

• Require every migrated workload to have a clear owner. If no one owns it, do not move it.
• Start data and integration work early, especially when moving from on-premises to cloud.
• Plan for format, collation, character setting, networking and firewall challenges.
• Onboard users early, even when feedback is tough, so the team can correct course before the migration scales.

The results show both technical progress and organizational change. Legacy ETL workloads ran faster on Viya. Users saw even greater improvements when they optimized their own projects. The company moved to full version control and DevOps-style deployment practices, with 1,100 commits to its production repository in 2026 alone. It also onboarded 1,400 users, more than 10% of the company, to actively use SAS Viya for analytics and reporting.

Posten Bring’s migration mantra is clear: migration is not just about moving systems. It is about moving the organization forward.

Regeneron: Strategy drives execution

Regeneron’s story reinforces the modernization theme from a different perspective. The company set out to “accelerate data to insight” by building a modern, multilingual statistical computing environment around SAS Viya. The goal was not simply to replace SAS 9.4 or SAS Grid. It was to create a broader analytical ecosystem designed for the way regulated life sciences teams need to work today and in the future.

In clinical research, governance is not an add-on. It is fundamental to protecting sensitive patient data, supporting auditability, and proving that outputs were produced in a controlled, compliant way.

Regeneron also recognized that users need choice without fragmentation. Its unified analytical platform combines SAS Viya with Posit and a common shared storage layer so programmers and data scientists can work across SAS, R, Python, and future tools without duplicating data or weakening governance. The idea is simple but powerful: one governed data foundation, multiple best-fit tools and a consistent user experience people are willing to use all day.

For Regeneron, AI should not sit off to the side as another disconnected tool. It should work naturally across SAS Viya, Posit and future tools, using secure common protocols so users can ask questions, get answers and receive recommendations without leaving the governed ecosystem.

That strategy-first approach shaped the migration itself. Before moving workloads at scale, Regeneron invested in:

• Stakeholder alignment across IT, business, and statistical programming leadership.
• Rigorous planning, including detailed Gantt charts, risk and pitfall analysis, and mitigation strategies.
• Validation strategy and change management before workloads moved at scale.
• Early user engagement with business SMEs.
• A “test small, scale big” approach using sample workloads in development before production.
• Close coordination across IT, business, storage, CloudOps, SAS, implementation partners and other technology providers.

The technical work was substantial. The migration required  changes dataset encoding issues, PROC IML image-generation workflows, Enterprise Guide-to-SAS Studio change management, log-line limits, POSIX permission challenges and validation requirements across AWS, storage, SAS Viya, R packages, and third-party components. In a GxP-compliant environment, every component that data touches must be considered, validated, and governed.

By the numbers, Regeneron had migrated hundreds of users and expected to reach 400 by the end of the journey, with millions of files and roughly 90 terabytes of legacy data in scope. The roadmap began with strategic planning in 2024, moved through non-GxP and GxP platform go-lives in 2025, launched pilot and wave-based migrations in 2026, and is expected to culminate in a modern, multilingual, modular, AI-enabled, cloud-native, and GxP-compliant statistical computing environment heading into 2027.

Regeneron’s migration mantra is equally clear: strategy drives execution. Or put another way, design with intention, execute with discipline and scale with confidence.

What these stories teach us

Posten Bring and Regeneron approached modernization from different starting points. One story centers on resilience, adaptation and bringing a long-standing organization forward. The other centers on strategic platform design, governance, and future readiness in a highly regulated environment.

Together, they point to the same conclusion in that migration is not the finish line. It is the mechanism organizations use to become more adaptive, more governed, more scalable, and ready for what comes next. That requires more than moving code and data. It requires clear ownership, engaged users, executive commitment, disciplined planning, trusted partners, and the willingness to rethink how work gets done.

The organizations that get the most from modernization are not simply asking, “How do we move what we have?” They are asking, “What do we want to become?”

That is why the best migrations don’t just move workloads. They move organizations forward.

Learn more

• From SAS 9 to SAS Viya: Modernize analytics without starting over
• Streamline Your Migration to SAS Viya 4 With Time-Saving Automation
• Modernizing to SAS Viya – Tips, Tricks and Lessons Learned
• SAS9 to SAS Viya: How to Streamline Your Migration

Modernization lessons from Posten Bring and Regeneron was published on SAS Users.

What many people didn't realize was that Lex Jansen was a real person.

We learned the sad news this week that Lex passed away. And his site, which has helped thousands of SAS users over the decades, is now gone. These are two huge losses for the global community of SAS users.

His passion project: make information accessible

Lex built and maintained lexjansen.com, a personal, not-for-profit project that became one of the most valuable resources in the SAS ecosystem. The site indexes tens of thousands of papers from SAS Global Forum, PharmaSUG, PHUSE, regional user groups, and countless other conferences, providing a powerful search experience across decades of technical knowledge.

That's perhaps one of the highest compliments a technical contributor can receive. Lex built something so useful, so dependable, and so enduring that it became infrastructure. His work quietly enabled the success of thousands of others.

Before modern search engines became as capable as they are today, lexjansen.com set the standard for finding relevant technical content. Even now, many experienced SAS professionals will instinctively type their search terms into Lex's site before trying anything else. The site's carefully curated indexing and search capabilities often made it easier to find the right paper than searching the conference websites themselves.

For countless users, "Lex Jansen" became synonymous with the site itself. Many learned how to use lexjansen.com long before they ever learned there was a person behind it. Some never knew at all.

Stalwart contributor to clinical data standards and the pharma industry

Throughout his career, Lex had many "day jobs" aside from building his website for SAS users. He worked on methods and data formats for clinical data and pharmaceutical submission standards, including CDISC and Define-XML. After years of prior experience in the industry, Lex joined SAS and worked on offerings such as SAS Clinical Standards Toolkit and SAS Life Science Analytics Framework. He later retired from SAS, but went to work for CDISC where he continued his work toward improving the data standards process and helping others in the industry to learn. (See this remembrance from his CDISC colleagues.) All the while, he continued to add content and index rules to lexjansen.com, so SAS users could always find the latest and best published information.

A personal remembrance

Like many people, I knew lexjansen the site long before I met Lex Jansen the person. I got to know him just a little bit during his time at SAS and during the annual PharmaSUG conference, where we could meet up in person. Since my team at SAS curates the content from SAS conferences, I worked with Lex to get that content indexed for his site. Most recently he added the content for SAS Innovate 2026. He was a super nice and approachable colleague and friend, and always very responsive to every request.

On a personal level, we recently compared photos from our respective trips to Iceland. Lex traveled there in June 2026, whereas I had been there in March. We both found it to be a beautiful country with amazing history and culture, but our climate experiences were very different! My trip was during Winter; Lex was there in the Spring.

Living in a world without lexjansen.com

The loss of Lex's site is a setback for SAS users -- but we still have access to the decades of content that the site made easy to search and find.

The goal of lexjansen.com was to index all of this published SAS content to make it easily searchable. But most of the actual published papers are hosted elsewhere. For example, you can find links to all SUGI/SAS Global Forum/SAS Innovate sessions here.

PharmaSUG proceedings are at the PharmaSUG site: https://pharmasug.org/past-conference-proceedings/

Many of the other regional/large conferences are also self-hosting their papers. Over time, I know the community will come together to fill the gap left by Lex, inspired by Lex's work and his acts of service for us all.

Update: this work has already begun. Check out these sites (added from the comments):

• https://www.clinyun.com/ppi/
• https://www.clinstandards.org/conference-papers

Remembering Lex Jansen: Friend to SAS learners everywhere was published on SAS Users.

The Model Registration node in SAS Model Studio (2026.05) gives that logic a home. Because the node accumulates score code from every preceding node in the pipeline, any post-model adjustment you build with a SAS Code node travels with the model into SAS Model Manager. You register one artifact that already knows how to produce the business-ready output.

A use case: weighting predictions for decisioning

We will use HMEQ, the home equity loan dataset many SAS users already know. The target BAD flags whether an applicant defaulted. The model returns a probability of default for each application. The credit team, though, does not act on probability. They act on dollars at risk. A 40% default probability on a large, requested loan is a bigger exposure than a 70% probability on a small one.

The fix is a single derived score: expected loss, calculated as the default probability multiplied by the requested loan amount. It is a trivial expression. The hard part has always been keeping it attached to the model. Build it in a SAS Code node placed after the modeling node, and the Model Registration node carries it through to Model Manager as part of the published score code.

Step by step in Model Studio

1. Build the baseline pipeline. Start from the Data node with the HMEQ data and BAD assigned as the target (event level 1). Add any preprocessing you’d like, then add a Supervised Learning node such as Gradient Boosting. Run it. Note the posterior probability variable the node generates, P_BAD1.
2. Add a SAS Code node after the modeling node. Connect the Supervised Learning node to the SAS Code node so that its parent already generates score code. This placement is what lets the SAS Code node contribute to the accumulated score code downstream.
3. Author the weighting logic as score code. In the SAS Code node editor, add the expression that creates your derived output variable:

/* Expected loss: weight the default probability by the requested
loan amount so reviewers can rank applications by dollars at
risk, not probability alone. */
length EL_dollars 8;
EL_dollars = P_BAD1 * LOAN;

‘LOAN’ is already an input in HMEQ, so it is carried through the pipeline and available when the published model runs. If you derive the weight from a variable that is not a model input, make sure it is retained so scoring can reach it.

4. Run the SAS Code node. Confirm ‘EL_dollars’ appears in the output and the values look right against a few known records.

   

5. Add a Model Registration node after the SAS Code node. Run it. The node accumulates score code from both the Supervised Learning node and the SAS Code node, along with the artifacts required to register the model.

   

6. Register or publish from the node menu. The Model Registration node does not register automatically. Once it has run successfully, use the node menu options to register the model to SAS Model Manager, and publish to a destination if you are ready.
7. Verify in Model Manager. Open the registered model and confirm the score code includes the ‘EL_dollars’ calculation. The weighting logic is now part of the governed model, not a separate step someone has to remember to rerun.

What you have built

In a few steps, we took a standard supervised pipeline and made it carry its own decision logic. The Supervised Learning node produces the default probability; the SAS Code node turns that probability into expected loss in dollars, and the Model Registration node packages both into a single model registered in SAS Model Manager.

The advantage is that the business logic and the model are now one governed artifact. The expected-loss calculation is no longer a separate script that someone must remember to run, reconcile, or update when the model is refreshed. Whoever scores the model gets dollars at risk directly, computed the same way every time. The logic is versioned with the model, visible in Model Manager, and travels wherever the model is published. You register once, and the decision-ready output comes with it.

Learn more

• Conversational pipeline building with SAS Viya Copilot in Model Studio
• SAS Viya Workbench & SAS Model Manager for Model Training and Deployment: SAS Models
• From fraud detection to fraud resolution: Building an AI voice agent with SAS Viya and LLMs
• Unlocking agentic AI potential with MCP tools in SAS Retrieval Agent Manager

Registering the whole pipeline, not just the model was published on SAS Users.

Most SAS 9 programmers are used to writing the code, running it, checking the log, fixing what broke, and running it again. Agentic AI can take on parts of that loop, but only if it can do more than answer a question. It needs to write or revise code, run it, inspect the results, and keep working until the output meets the goal.

For SAS 9 programmers, the setup is not as simple as picking an AI model and turning it loose. SAS 9.4 is not built for agentic AI in the same way newer SAS Viya environments are, so you need a bridge between the AI tool and the SAS 9 environment. A useful way to think about it is in three parts: the interface, the agentic AI tool, and the connection back to SAS 9.

1. The interface: Where the work happens

The interface is where you give the AI its instructions, watch what it is doing, and step in when needed. You can use a command line, an IDE such as Visual Studio Code, or a chat-like interface. For SAS 9 programmers, the IDE option is usually the most practical because you can see the generated SAS code, files, logs, and agent conversation in one place.

That visibility matters. If the agent is writing DATA steps, PROC REPORT code, PROC SQL, or ODS output, you still need to review the logic, check the log, verify the results, and make sure the output fits the business need.

2. The agentic AI solution: The system that plans, codes, and iterates

The second piece is the agentic AI tool itself. That might be Claude Code, ChatGPT Codex, or another tool. The important point is that the AI can break down a task, use tools, run SAS code, look at the results, fix errors, and try again.

That changes what the SAS 9 programmer does. You are not writing every line by hand. You are explaining the task, giving the agent the data and environment details it needs, and then reviewing what comes back. It is still programming, just one level higher.

That is why SAS knowledge still matters. The AI can help with syntax, boilerplate code, report generation, data exploration, and first-pass debugging. But you still need to know whether the output makes sense, which SAS procedures are appropriate, and where the agent may be taking a shortcut.

3. The SAS connection: The bridge between AI reasoning and SAS execution

The third piece is the connection to SAS 9. This is what turns the workflow from code suggestion into something useful. Without the connection, the agent can write SAS code but cannot test it. With the connection, it can submit the code, read the log, inspect the output, correct mistakes, and keep going.

For SAS 9.4, SASPy is that practical bridge. It lets Python connect to SAS, submit SAS programs, and bring data or ODS results back into Python. That matters because many agentic AI tools are comfortable working in Python, while the SAS program stills runs natively in SAS 9.

This is where SAS 9 differs from Viya. SAS Viya has tools such as SAS Viya MCP that are built for agentic AI. SAS 9.4 needs a more hands-on setup. For many SAS 9 programmers, that means using SASPy with a connection method such as SSH, IOM, or COM so the AI can submit code to the SAS server and bring results back for review.

Want to see it work? Watch the SAS Innovate 2026 demo from Joe Matise, NORC to see Claude Code use SASPy to run SAS 9 code, review results, and fix errors.

Want to get the files? Visit Joe’s GitHib repo.

Prompt engineering is the operating discipline

Prompt engineering is a new part of the programmer’s job in this workflow and includes the agent settings, reusable pre-prompt, and the actual prompt. The settings affect what the agentic AI is able to do. The actual prompt is where you tell the agent what to do, where to put files, which data set to use, what the output should look like, and to run and validate the result for a given project. The reusable pre-prompt is more like onboarding a new employee. It gives the agent the guidance you would give a new SAS programmer: environment details, file path rules, SASPy or Connect SASPy instructions, preferred coding patterns, and reminders to check the log.

Verification, validation, and data handling still matter

Agentic AI can speed up SAS 9 coding, but it does not remove the need for judgment. You still need to review the generated code, inspect the SAS log, confirm that the output was created correctly, and decide whether the results are ready to share.

Data handling deserves the same care. If the work involves sensitive data, know what the AI can see and what your policies allow. One practical pattern is to let the agent work with test or de-identified data, then have a human move the reviewed code into the production environment.

Bottom line

Using Agentic AI with SAS 9 is not just about the AI model. The goal is to set up a workflow where the agent can help, but the SAS programmer still understands, reviews, and owns the result. The three pieces are straightforward: a good interface, an agentic AI tool, and a reliable connection to SAS 9.

When the setup works, Agentic AI can help SAS 9 programmers get to a solid first program faster. It can explore data, generate code, and catch errors, but the programmer still owns the result. The value comes from pairing the AI’s speed with the programmer’s review, validation, and domain expertise.

Learn more

• SAS 9.4 M10: Continuing Support and Roadmap in the Era of Viya
• Ask the Expert webinar: “Empower Your AI Agents With Analytics and Decisioning Expertise With SAS MCP Server”
• Introducing the SAS Agentic AI Accelerator: Build AI Agents Seamlessly in SAS Viya
• Unlocking Agentic AI Potential with MCP Tools in SAS Retrieval Agent Manager

The three components you need to use agentic AI with SAS was published on SAS Users.

SAS 9 is trusted because teams rely on its consistency, accuracy and governance for decisions that matter. It is familiar because users know how to work with it  and deeply embedded in the workflows, reports and processes that turn data into insight.

SAS Viya is the next generation of the SAS platform. It helps organizations evolve beyond SAS 9 by modernizing the data and AI life cycle, from data management and analytics to AI development, deployment and operational decisioning. Teams can work faster, collaborate more easily and move analytics into production with less friction. They also have the flexibility to deploy across cloud, hybrid and on-premises environments while keeping the governance and analytical rigor they value from SAS.

The question for many SAS 9 customers is not whether to modernize, but where to begin and how to do it in a way that builds on the SAS programs, data pipelines, reports and user expertise already in place.

Modernize with purpose

Modernizing SAS Viya does not have to be an all-or-nothing decision. It can begin with a specific business need, such as accelerating an AI use case, scaling a high-value analytics workflow, or helping SAS, Python and R users collaborate more easily in one governed environment.

Four areas show where Viya can make that difference: AI assistance that helps people work faster, agentic AI that connects insight to action, open collaboration across SAS, Python and R, and scalability for meeting data and AI demands.

1. Work with AI assistance across the data and AI life cycle

SAS Viya Copilot helps make analytics more approachable and productive by bringing natural language assistance into the way people already work. Users can ask questions, get guidance in context and move from data to insight without relying on every step being manual or highly specialized. For example, Copilot can help users code, explore data, generate explanations, identify next steps and complete common tasks more efficiently.

That matters for teams trying to do more with limited time and resources. In Viya, Copilot is connected to the data and AI life cycle, so users can work faster, build confidence, and stay within a governed SAS environment instead of moving work into disconnected tools.

2. Move from insight to governed action with agentic AI

AI is evolving from systems that generate answers to systems that can help analyze, decide and act within business workflows. In SAS Viya, agentic AI can connect data, analytics, decisioning and governance so AI-supported actions are transparent, controlled and aligned with business rules.

That can help teams move beyond recommendations to action, such as prioritizing a fraud alert, triggering a next-best offer, routing a service issue or applying a policy decision, while keeping humans in the loop where judgment and accountability matter. For organizations, the value is not simply automation. It is trusted automation, with oversight where it matters.

3. Bring SAS, Python and R teams together

Modern analytics teams rarely use one language or tool. SAS, Python and R users often need to work on the same problems, such as preparing data, testing models, comparing methods or sharing results, even when they start from different tools and workflows.

SAS Viya brings those ways of working together in one governed environment. Teams can use familiar tools, reuse existing SAS assets, collaborate on common data and models, and move work from experimentation to production with more consistency, control and scale.

4. Scale confidently as data and AI demands grow

Analytics workloads rarely stay the same. Data volumes are growing; more users need access to insight and AI projects can require significant compute. SAS Viya gives organizations the flexibility to scale analytics as demand changes, instead of being limited by environments that were not designed for today’s data and AI workloads.

With Viya, teams can support more users, run more workloads and choose deployment options that fit their environment, including cloud, hybrid and on-premises. For example, organizations can expand capacity for model training, support seasonal demand spikes and give more teams access to shared analytics resources.

SAS Managed Cloud Services can also help reduce the operational burden of managing the platform, giving teams another way to modernize while focusing more on analytics outcomes than infrastructure management.

What this means for SAS 9 customers

Together, these areas point to a bigger shift. Instead of treating analytics as a set of separate tasks, organizations can manage data, AI and decisions as a connected, governed life cycle. AI assistance, agentic AI, open collaboration and cloud scale support each shift by helping teams work faster, move from insight to action, collaborate more easily and create room for future growth and innovation. The opportunity is to make modernization focused, achievable and tied to business value. Start with the work that matters most, then build from there.

Ready to explore your Viya path?

If your team is already delivering value with SAS 9, Viya can help you build on that foundation. Start with the opportunity that matters most, whether that is faster AI development, smoother collaboration, easier deployment or greater scale. Connect with us to start the conversation.

Additional resources

To go deeper, explore these resources:

• SAS Viya Copilot: Learn how natural language assistance can help users work faster across the data and AI life cycle.
• Agentic AI: Explore how AI agents can support governed decisions and actions.
• SAS open-source integration: See how SAS, Python and R users can work together in one governed environment.
• SAS Viya Workbench: On-demand computing power and self-service flexibility for fast SAS, Python or R coding.
• Move to SAS Viya webinar series: On-demand sessions showing clear migration pathways, product walk-throughs and demos from SAS Enterprise Guide® and SAS Analytics Pro transitions to data integration, visual analytics and modeling.
• SAS Managed Cloud Services: Learn how managed services can reduce operational complexity.

From SAS 9 to SAS Viya: Modernize analytics without starting over was published on SAS Users.

A chat window opens. A question surfaces. An answer comes back before momentum fades. That conversational experience is powerful precisely because it keeps insight close to the work. But there's a version of assistance that goes even further – one that doesn't wait to be asked.

In the third blog post in this series, we explored how SAS® Viya® Copilot introduces a conversational AI assistant into SAS® Visual Analytics to help users explore data, create reports, and surface insights through natural language. The chat experience is powerful precisely because it keeps users inside the analytical environment while questions surface and evolve.

But conversation and embedded assistance are two different things.

If the chat interface puts SAS Viya Copilot alongside your work, the capabilities we’re exploring now put it inside the work itself. No chat pane. No context switch. Assistance that surfaces at the moment a task begins and stays out of the way the rest of the time.

The hidden costs of routine tasks

In the second blog post in this series, we identified the execution gap: the space between having analytical capability and actually sustaining the momentum to act on it. A large share of that gap isn’t caused by complex problems. It’s caused by repetitive ones:

• Preparing data for effective insights.
• Interpreting what a visualization is showing.
• Translating reports for global audiences.

These tasks often require manual effort, domain knowledge, or additional context switching that slows users down. Viya Copilot’s in-context capabilities are designed to address exactly this. Not by removing users from the workflow, but by surfacing GenAI assistance directly within the interface where the work is already happening.

Grouping without the grind

Creating custom categories is a common part of preparing data for analysis. Users often need to organize raw values into higher-level, more meaningful groupings:

• Cities into geographic regions.
• Products into brands or product families.
• Departments into business units.

Traditionally, this process requires users to manually create groups and assign values one by one – a task that can become time-consuming when working with large or unfamiliar datasets.

With SAS Viya Copilot, users can generate these value groups automatically using generative AI directly within the custom category workflow.

For example, a user working with a list of cities can ask Copilot to generate geographic regions. Similarly, product names can be grouped into likely brands or categories without requiring manual assignment of every individual value.

The workflow also supports iterative refinement. Users can provide additional context to the value group generation, which can be either instructional ("Create 4 groups") or clarifying ("STATE refers to the current status"), and then regenerate the groupings.

For added transparency, users can view an explanation of what external data Copilot used to generate the value groups.

Summaries that explain the story behind the visual

Charts and visualizations communicate information quickly – but interpreting what really matters within a graph can still take time.

With SAS Viya Copilot, users can generate on-the-fly natural language summaries that are grounded in the data. Copilot analyzes the visual and generates a concise narrative summary that highlights important analytical insights and patterns, including trends, correlations, seasonality and potential outliers.

These summaries can help users interpret findings more quickly – especially when exploring unfamiliar data, reviewing complex dashboards, or preparing executive summaries based on detailed reports.

For example:

• A time series visualization might highlight seasonal trends or unexpected spikes.
• A scatter plot summary could identify strong correlations or notable outliers.
• A bar chart summary may call attention to top-performing categories or unusually large gaps between groups.

This capability is particularly valuable because it aims to reduce the time-to-insight between seeing a chart and understanding its meaning.

Localizing reports for global audiences

In an increasingly global workforce, organizations often need to distribute reports across teams, regions, and countries where users speak different languages. Translating report content manually is often time-consuming – especially when dashboards include many pages, prompts, labels, and visual elements.

SAS Viya Copilot helps streamline this process by embedding AI-assisted report localization directly in SAS Visual Analytics. After a target language is chosen, Copilot generates translated labels for report elements, including page names, chart titles, and other report text content.

Users can then review the generated translations for appropriateness or export the translated text for additional review or collaboration.

Users can also refine the results by specifying additional information or instructions to help guide the generated values. This additional guidance capability is especially useful when working with industry-specific terminology, brand language, or regional phrasing preferences.

SAS Visual Analytics also maintains transparency throughout the experience. Translations generated by AI are clearly marked, allowing users to distinguish AI-generated content from manually created content.

AI that’s integrated into the analytics experience

One of the most important aspects of these embedded capabilities is that they do not feel separate from the application.

This matters because the most effective AI experiences are often the ones that reduce friction and context switching. SAS Viya Copilot enhances existing workflows with targeted assistance exactly where users need it, maximizing productivity.

In the next post in this series, we’ll explore how SAS Viya Copilot combines GenAI assistance with advanced models to help users uncover deeper insights and accelerate analytical decision-making.

Learn more about how SAS Viya Copilot helps organizations turn analytical power into sustained decision momentum.

How SAS Viya Copilot works inside the task, not alongside it was published on SAS Users.

When did we have the highest profit?
Which customers are driving growth?
What segment should we look at next?

In traditional analytic workflows, turning those questions into answers often requires navigating menus, configuring visuals, writing calculations and interpreting results before a story emerges.

In the last blog post in this series, we explored how SAS^® Viya^® Copilot changes the traditional analytical experience inside SAS^® Visual Analytics.

Embedded directly in SAS Visual Analytics, Copilot introduces a conversational AI assistant that helps users explore data, create reports, and interpret insights through natural language. By combining generative AI with the analytical capabilities of the SAS Viya platform, Copilot transforms business questions into analytical actions, recommendations, and explanations – creating a more fluid analytics experience.

Let's explore how Viya Copilot can help you move from question to clarity faster than ever.

Analytics that meet you where you are

Analytics doesn’t happen in a single step. It unfolds across stages:

• Exploring and shaping data.
• Building visualizations and reports.
• Interpreting insights.

SAS Viya Copilot supports users throughout this journey – users simply need to ask.

A more natural way to work with data

Understanding the data is at the center of answering any business question.  For many users, this early stage of analysis can take time – especially when working with unfamiliar datasets.

Within SAS Visual Analytics, Copilot simplifies this process by acting as a guide to the data – helping users explore, understand and prepare their data for further analysis.

• To make the data fit-for-purpose, Copilot can change a data item’s properties – including the label, format and aggregation.
• Copilot can also assist with common data transformations, including creating groups or bins from categories, defining hierarchies, and preparing data items for time-based or geospatial analysis.
• Preparing data often requires creating entirely new calculations to answer a particular question. Instead of manually writing expressions to determine growth rate or profit margin, Copilot can generate new calculations from simple natural language.

This conversational interface lowers barriers for business users while accelerating exploration for experienced analysts.

From data to visuals – faster

Designing dashboards and reports often involves a series of manual steps – selecting visuals, assigning data roles, adjusting formatting, and refining layouts. Copilot helps streamline the process, enabling users to go from raw data to meaningful visual stories faster.

• Copilot can generate new report pages from scratch, automatically creating relevant visuals - like charts, tables, and other content like titles, headers and footers – based on your business question or area of analysis.
• Designing dashboards is an iterative process – Copilot can refine existing reports by adding new visuals to the report page, replacing or changing existing visuals to show data in a different way, or deleting visuals or other content that are no longer relevant.
• Copilot can focus insights by applying filters, ranks, display rules or interactions to existing visuals, helping narrow attention to the most relevant information.

The goal is to remove friction from the workflow so users can work more efficiently. By automating many of the tasks involved in report building, Copilot enables designers to focus their time on communicating the story behind the data.

Insights only a question away

Reports and dashboards provide insights – and often lead to brand new questions. The conversational nature of Viya Copilot allows users to ask questions about their data and quickly receive tailored on-the-fly responses in real time.

• Copilot can create ad-hoc visualizations that help answer a user’s question. The categories, measures, and any additional logic – such as applied filters or ranks – are visible to the user, ensuring transparency into how the insight was produced.
• New questions often emerge mid-analysis. Copilot retains the conversational context from earlier interactions to handle follow-up questions seamlessly.
• Copilot can summarize visualizations, highlight key trends, and generate visual explanations that help users better understand relationships between important variables.

In this way, curiosity becomes part of the workflow. Questions surface and can be explored immediately with Copilot acting as a collaborative AI assistant.

A faster path from curiosity to clarity

SAS Visual Analytics has long included augmented analytics capabilities that automatically surface insights, highlight drivers, and explain outcomes. Viya Copilot builds on that foundation by adding generative AI to the experience.

With Copilot, analytics becomes conversational. This creates a more collaborative relationship between the user and the analytics platform - one where the system actively helps users navigate their analytical journey.

In the next blog post, we’ll focus on the Copilot capabilities available outside of the chat pane – embedding GenAI experiences directly into the user workflow for targeted assistance.

Learn more about how SAS Viya Copilot helps organizations turn analytical power into sustained decision momentum.

From question to clarity: how SAS Viya Copilot changes the way we work with data was published on SAS Users.

Whether your day‑to‑day work happens in SAS 9, SAS Viya, or a thoughtful combination of both, SAS Innovate brings together the people, ideas, and practical guidance that help you get more value from SAS today —- while preparing for what's next.

This year's event doubles down on what SAS users have always valued most: learning from each other, sharing real‑world experience, and finding practical ways to work smarter with the tools you already rely on.

SAS Users Day: Powered by the community

One of the highlights of SAS Innovate 2026 is SAS Users Day -- an afternoon focused completely on SAS users as presenters and audience.

SAS Users Day celebrates the way SAS professionals learn best: through user groups, communities, and peer‑to‑peer knowledge sharing.

If you've ever picked up a tip at a local user group meeting, learned something valuable from a SAS Communities post, or borrowed code from a fellow user, SAS Users Day will feel like home. SAS Users Day takes place on Monday afternoon featuring experienced conference presenters, ending with a bit of social time for networking with your fellow users.

Expect:

• Sessions led by active SAS user group members
• Stories that reflect real constraints, real deadlines, and real wins
• Plenty of opportunities to connect with people who speak your SAS language

It's a reminder that while software matters, the SAS user community is one of the platform's greatest strengths.

SAS 9: Productive today, Preparing for tomorrow

Presenters in the SAS 9 track include current SAS users, as well as developers in R&D's SAS 9 division who support the platform. What you'll learn:

• How other teams are keeping SAS 9 fast, stable, and reliable for real production workloads
• Simple, proven ways to clean up, manage, and future‑proof long‑lived SAS code
• Where SAS 9 still shines -- and where it makes sense to complement it with newer tools (including AI!)
• Practical patterns for integrating SAS 9 with cloud services, APIs, and open source
• Real stories from customers who are successfully running SAS 9 today (and planning tomorrow)

SAS Innovate works because of SAS users -- and it's built to work for you. Register now, and we'll see you there!

SAS Innovate 2026 and you: the SAS user was published on SAS Users.

Introducing Iceberg support

Today I'd like to share a very exciting development to the SAS/ACCESS Interface: enhanced Iceberg support! As the mountain of data organizations face continues to grow exponentially, it's no surprise that cost-efficient data storage solutions have become a major focus. This focus is two-fold: where do we store our data, for one, and equally important, how do we store our data?

Open file formats like Parquet and Avro are excellent solutions for the latter question, but depending on your choice of storage solution, you might still experience high latency, poor performance, and dangerously high storage costs. Your storage strategy, of course, is likely stratified based on data access frequency and purpose, so it's unlikely to see an organization's entire corpus of data sitting in the same solution. Nonetheless, wherever you keep your data, you'll want your storage affordable and your access efficient. DuckDB and Iceberg, used in tandem, can provide an easy, readable, and efficient methodology for accessing, querying, and even editing data while stored in cost-conscious locations. And now, as of SAS Viya's 2026.01 release, you can wield all that power yourself, from the comfort of your own LIBNAME.

Let's dig in on the what, where, and how!

Where's on First

To be clear, this demonstration is surely not the only way to combine SAS, DuckDB, and Iceberg, but I've found it particularly easy, both as an administrator setting it up, and as a user leveraging it. From an admin perspective, the location we'll be keeping our data in today is AWS's S3 - but not the traditional buckets for object storage. Instead, we'll be using S3 Table Buckets, which use Apache Iceberg to manage tables as objects, rather than just files. This is supremely important when working with open file formats like Parquet, because the number one detractor from Parquet is the computational difficulty in editing it. Parquet is highly effective for querying thanks to its columnar nature and paginated metadata, but it requires full file re-writes in order to effect change. Iceberg, as a table format, mitigates this by using metadata files to manage versioning (among many other benefits) of the data they govern. As the top layer, S3 Table Buckets abstract all of these mechanisms away from the user, so all we see are query-ready tables in a conventional database structure.

How's on Second

By this point, the how is probably pretty clear: the joint operation of the SAS/ACCESS Interface to DuckDB. SAS/ACCESS Interfaces have long been used to connect to remote data sources in SAS 9 and Viya alike. But the DuckDB Interface brings a slightly different modus operandi; rather than being specifically designed to connect to a SINGLE type of data source (i.e. ACCESS to Snowflake, Databricks, etc.), the DuckDB ACCESS Interface can explicitly extend to ANY cloud storage supported by DuckDB's vast extension mechanism. This extension mechanism is exactly what we'll be leveraging behind the scenes to establish a connection to Iceberg Tables, in this case those located on S3 Table Buckets.

To connect to Iceberg tables in an S3 Table Bucket, all we need is a LIBNAME statement, just as we would connect to any other remote data source. Here, duckdb is the engine name, and bowser is the library name:

libname bowser duckdb file_type=iceberg
  iceberg_catalog='arn:aws:s3tables:[region]:<account-number>:bucket/[bucket-name]'
  iceberg_endpoint_type=s3_tables
  s3_access_key=&s3key
  s3_secret=&s3secret
  s3_region='[region]'
  schema='[schema-name]';

Here's what you need to make this work:

1. Find the Amazon Resource Name (ARN) of your Table Bucket. This value (in quotes) will be the iceberg_catalog option.
2. Declare the file_type option to be iceberg and the iceberg_endpoint_type to be s3_tables. Note that while you can write a large portion of SAS code without any regard to capitalization, the values for these options MUST be lowercase.
3. Define your s3_access_key and s3_secret. For general best practice, I used macro variables that I declared elsewhere (in single quotes). These credentials should be tied to a user in your AWS account that has read & write access to the source Table Bucket.
4. Define the s3_region of your bucket. It's always good practice to keep your cloud resources in the same region when possible, as cross-regional data movement introduces extra latency.
5. The last thing you'll need is the schema value. When looking inside your Table Bucket from the S3 GUI, you'll notice each table has an associated namespace. This value is the schema in the full qualified table location - so any given table in the bucket could be accessed explicitly at: iceberg_catalog.<namespace>.<table>.

Once you have all this information, you're ready to test out your new DuckDB-powered Iceberg-backed LIBNAME! You'll notice that just like a traditional Library, your member tables are all present on the left-hand side of the GUI, as seen below. This presence is a slight distinction from some other SAS/ACCESS to DuckDB use cases, where connections to external cloud storage defined within explicit single-transaction PROC SQL / CONNECT statements would, by design, not be considered member tables. I consider the LIBNAME options as a best practice regardless of the data storage to which you’re connecting. Learn more about the options in the LIBNAME statement here.

What's on Third

What I've done to the classic Abbott & Costello skit at this point is unforgiveable, but I'm in too deep to stop now. Let's get some SAS code on the board and showcase the ease and speed that SAS/ACCESS to DuckDB to bring to your Iceberg tables. Simplest behaviors first: how do we read Iceberg tables?

PROC SQL outobs=10;
  SELECT * from BOWSER.target;
QUIT;

When we were defining the LIBNAME, I mentioned that the S3 Tables each had fully qualified names. This is useful here, because many programmers, including myself, like to use database-specific flavors of SQL. If you're a big fan of DuckDB's SQL flavor syntax, then explicit passthrough in PROC SQL is for you:

PROC SQL;
  CONNECT USING BOWSER;
  SELECT * FROM CONNECTION TO BOWSER (
    SELECT * FROM iceberg_catalog.main.target LIMIT 10
  );        
QUIT;

Using the full name iceberg_catalog.main.target, we can use DuckDB-specific SQL on our S3 Table. Given the breadth of DuckDB's SQL capabilities, this serves as a powerful connection without too much of a change to the PROC SQL wrapping syntax. Note that in both the implicit and the explicit passthrough scenarios, we are required to pay attention to capitalization for the bucket-specific resources. It doesn’t matter whether the LIBNAME is capitalized, but the case of the schema and table names must match their definition in the bucket.

Thanks to advancements in DuckDB itself at the tail end of 2025, SAS/ACCESS to DuckDB can not only read from Iceberg tables, but also write!

PROC SQL;
  CREATE TABLE BOWSER.line_items AS
    SELECT * FROM WORK.line_items;  
QUIT;

Once again, there's no deviation from the standards of PROC SQL in table creation. This exact code might be useful if we wanted to transfer a SAS table (the above being from the TPC-H datasets) into an Iceberg Table in S3 as part of our storage strategy. In our S3 Table Bucket, we can validate that the new line_items table has been created:

Maybe we want to perform some changes to this table down the line. If this table were stored simply as a Parquet file in a bucket, this would be a computationally expensive hassle, but thanks again to Iceberg, edits on these table objects are easy!

/* How many records do we have to start? A: 6001215 */
PROC SQL;
  SELECT COUNT(*) FROM BOWSER.line_items;
QUIT;
 
/* Delete all the records with ship-date before 1993 */
PROC SQL;
  DELETE FROM BOWSER.line_items
    WHERE L_SHIPDAT <= '01JAN1993'd;
QUIT;
 
/* Validation: How many records now? A: 5242432 */
PROC SQL;
  SELECT COUNT(*) FROM BOWSER.line_items;
QUIT;

In just 8 seconds, DuckDB executed the removal of all records with a shipping date before 1993 from the table. Similarly, we can add or update records with ease. Do note the intricacies of versioning and deletions within Iceberg that allow for such efficient editing of tables backed in immutable formats. I consider it important to understand not just the fact that DuckDB and Iceberg together add value, but why they do so behind the scenes.

The one caveat before we check into the performance of SAS/ACCESS to DuckDB + Iceberg is the current limitations on the editing side. With real-world data, adding, updating, and deleting records aren't the only things that happen. Often times, we want to mutate the structure of a table itself: add, update, or remove columns. This is currently not supported in DuckDB itself, though DuckDB.org explicitly lists "schema evolution" in their near future planning. In the meantime, I highly recommend reading through the November announcement of write capabilities in DuckDB itself to learn the full extent of its capabilities.

Bringing it Home

I've harped on the value-add of DuckDB & Iceberg from the lens of SAS Viya for three bases now. Let's use a more in-depth query to validate the benefits. We'll use a widely popular (and freely available) dataset: the Yellow Taxi Trip Records courtesy of NYC.gov - specifically a single Iceberg table encompassing data from 2024, titled yellow_tripdata_2024:

The 41 million row dataset occupies 6.27GB sitting as a local .sas7bdat to the Viya environment, backed on a disk with NetApp Files Premium. For this test, we've gone ahead and pre-converted the dataset into an Iceberg table sitting in the S3 Table Bucket, where it occupies 656MB. With both versions of the dataset available, the test consists of a single implicit PROC SQL statement, seen below:

PROC SQL;
  SELECT
    passenger_count,
    payment_type,
    count(*)            AS num_trips,
    avg(trip_distance)  AS avg_distance,
    avg(fare_amount)    AS avg_fare,
    avg(tip_amount)     AS avg_tip
  FROM
    [library].yellow_tripdata_2024
  WHERE
    passenger_count is not NULL AND
    passenger_count > 0 AND
    passenger_count < 5 AND
    trip_distance < 100 AND
    trip_distance > 0
  GROUP BY
    passenger_count, payment_type
  ORDER BY
    payment_type, passenger_count; 
QUIT;

This query serves as a solid litmus test for overall engine performance, leveraging both CPU & I/O through its calculated columns, filtration, and ordering clause. We first ran it using a standard SAS Library connection to the data on the disk; then, we used the DuckDB Library to execute the query against the Iceberg table on the S3 Table Bucket. The test found a sizable improvement in both real-time and CPU-time performance by leveraging the S3 Table Bucket and querying it with the DuckDB engine:

Now, while these results are exciting, I want to point out that not every query, not every table, and certainly not every use case will reap the same benefits. For example, some downstream analytical procedures in the SAS software suite that can't be mimicked with a querying engine. But there are tangible, and sometimes massive, performance improvements that SAS/ACCESS to DuckDB can introduce to your pipelines. To boot, the S3 Table Bucket that we used to back this experiment is significantly cheaper than many of the high-performance storage disks. Here's a sample calculation based on current rates and size assumptions:

Migrating this individual workload not only noticeably improved performance, but it reduced the storage cost of the backing data by just about 99%, while also adding in the aforementioned benefits of Iceberg tables like time travel and versioning.

The last 7 months have brought incredible developments to SAS's integration with open file formats, and I'm personally thrilled to both witness and build with the resulting solutions in the SAS software suite. If you’re interested in learning more about the capabilities of SAS/ACCESS to DuckDB, I highly recommend taking the official SAS course: Working with DuckDB in SAS Viya®. It's quick, informative, and shows you a handful of tips, tricks, and best practices for maximizing the value of the engine. As always, thank you for reading, and I’ll see you at home plate.

Don't crash this ship! DuckDB is heading straight for Iceberg! was published on SAS Users.

At SAS, our Managed Cloud Services (MCS) division strives to meet these demands head-on through a powerful automation engine: the Engage platform.

Engage is a strategic automation framework that enables SAS to deliver cloud services with speed, precision and scalability. Whether supporting custom enterprise deployments or standardized offerings, Engage helps us deliver value faster and more reliably to our hosted customers.

What is Engage?

Engage is SAS’ internal automation platform designed to streamline service delivery across cloud environments. It powers everything from infrastructure provisioning to life cycle management, enabling self-service workflows and near real-time results. Built on modern cloud principles like Infrastructure as Code (IaC), DevOps, FinOps and security governance, Engage is the backbone of our cloud management strategy.

Within SAS Managed Cloud Services, Engage supports three core service lines:

• Managed Cloud Services Enterprise: Tailored infrastructure for high-revenue contracts.
• Managed Cloud Services Fleet: Immutable, standardized offerings for scale.
• Managed Cloud Services Developer Experience (DevExp): Automation and governance for internal teams.

Let’s explore how each delivers strategic value.

SAS Managed Cloud Services Enterprise: Custom Infrastructure at Scale

For customers with complex requirements, SAS Managed Cloud Services Enterprise provides tailored infrastructure and software deployments. Engage automates the sizing and provisioning process by pulling data from each customer’s Cloud Card and translating it into precise infrastructure builds using IaC.

Once the infrastructure is ready, build administrators use Engage to trigger software installations via auto-DaC workflows. This automation reduces deployment timelines and enables flexible customization, accelerating time to value without sacrificing control.

What’s the strategic value? Enterprise customers get access to bespoke environments faster, with fewer manual steps and greater consistency.

Managed Cloud Services Fleet: Immutable, Pre-Packaged Offerings

Managed Cloud Services Fleet is designed for scale. It delivers standardized SAS® Viya® environments, like  SAS® Viya® Essentials, that can be provisioned in under two hours. These offerings include pre-sized infrastructure and standardized software orders (e.g., Visual Analytics, Visual Statistics), all delivered through the Engage Catalog.

Because Fleet environments are immutable, lifecycle automation becomes predictable and reliable. Build administrators provide minimal inputs, and Engage handles the rest, right up to identity provider integration.

What’s the strategic value? Fleet enables rapid deployment at scale, making it ideal for SMBs, trials, and repeatable use cases.

Managed Cloud Services Developer Experience: Empowering Automation and Governance

Behind the scenes, our Developer Experience (DevExp) framework empowers SAS teams to build, deploy, and manage automation across hyperscaler environments like Azure, AWS, and Google Cloud.
DevExp includes:

• Code repositories and CI/CD pipelines.
• Governance tools for compliance.
• Integration with platforms like Azure DevOps and GitHub Actions.
• Self-service portals via MCAP, ServiceNow and Engage.
• Life cycle management for infrastructure and operations.
• A developer control plane for monitoring, logging, security and observability.

DevExp supports both Enterprise and Fleet offerings, ensuring automation is standardized, repeatable and scalable.

What’s the strategic value? DevExp enables internal teams to innovate faster while maintaining governance and transparency.

Continuous Innovation: What’s Next for Engage and Managed Cloud Services

Our journey with Engage is far from over. The platform is evolving to support AI-infused automation, deeper integrations with hyperscaler services, and expanded partner access. These innovations will further reduce friction, improve customer experience, and unlock new possibilities for service delivery.

As we continually modernize our cloud frameworks, Engage remains central to our strategy, helping us deliver smarter, faster and more secure cloud services.

Engage is setting a new standard for automation in SAS Managed Cloud Services. By combining self-service workflows, lifecycle automation and modern cloud principles, SAS is delivering faster outcomes and better experiences for our customers.

Interested in learning more? Read our white paper, Enabling data and analytics in the cloud.

Engage for Managed Cloud Services: Strategic automation for the future was published on SAS Users.

In SAS Viya 4, we can embed inputs directly on the reporting page with live results. These reports have code that takes user inputs and runs the program, which will run the dataset and update it with the most recent data. This gives the user the ability to create datasets on the fly and share the results with their teams.

We begin with our code, which creates macros that can communicate with our report and eventually the job that runs in the background of the report. Below (Figure 1), we can see the variables being brought into the code. They are then assigned values that will be used in our code and formulas (in my example, I have an optimization running in SAS code called Opt_Article.sas, which is where the macros are referenced). The code can then run in whichever program the user would like, but at the end of the program, there must be an upload process to get the final table into the CAS engine. Our table is named Project_Opt. This table will come into play later. For this example I am assigning values to project capacity, which could be used as budgets and time constraints.

For this code to update a report live, the code must finish with an upload statement that takes down the previous dataset and replaces it with the updated dataset with the same name (Figure 2).

The next step is to create a job in SAS. The user must create a new Job Definition and change the form to HTML. In the code, the user will need to create HTML code that reflects the inputs required by the macros. In Figure 3, the HTML for the inputs are shown. These allow the user to provide a base value and title for the input.

Then, the program side of the job must reference the code the user created that contains the formulas that utilize the macros (Figure 4).

On the right-hand side of the job interface, the parameters must be selected (Figure 5). This is where the macros need to be reflected for the report, matching the ones entered in the code and HTML. The additional parameters are for debugging purposes.

Figure 5: Input Parameters (left) and setting up the parameters (right)

Once this is completed, the job is ready for use. Copy the URL provided in the properties tab under Job URL (Figure 6).

Then, in a VA report, select the Web Content object. In the options tab of the object, place the URL. The job interface should appear. The user must then bring in the table that is created from the program, Project_Opt (Figure 7).

The data can now be shown in graphical interfaces. In the options tab for any graph using the table, select Periodically Reload Data and set a short timeframe. Then switch to non-edit mode and run the job (Figure 8).

The report should update as you run the submission, providing the updated dataset and report. This allows the user to share project results live with their teammates and gives non-coders the ability to manipulate the datasets to generate value for their workforce.

Update Data Live in SAS Viya: Integrating SAS Code with Interactive Reports was published on SAS Users.

SAS Viya has a large list of mapping shapes for geographic visualizations, but sometimes business units have custom regions that need to be displayed. These can range from individual counties, sales regions, postal codes, and voting regions. To properly visualize these regions, SAS has a process to bring in regions with custom borders.

SAS already has many regions preloaded into the system. When creating a new geography item in Visual Analytics, Viya has three options: Geographic name or code lookup, Geographic data provider, or Latitude and Longitude in data. For building regions that are already in SAS, select the geographic name or code lookup option. A drop-down list will appear asking for a Name or Code lookup (Figure 1).

Depending on the user data, the context will change. If the column has full country names, use Country or Region Names. If there are 2 letter state names, use that option. There are quite a few options (Figure 2) but for regions that cover whole states and do not have custom borders/shapes outside of political boundaries, the option of Subdivision (State, province) Names is ideal. When that option is selected, another drop-down will appear for the country that the data refers to, giving worldwide options for region shapes (Figure 3).

The user can now visualize the provinces/states for individual countries (Figure 4). But, sometimes these regions are tied together. To combine these predefined provinces, the user can create a custom category. In the data tab, create a custom category. Add the geography item created before to be “Based on”. Then add each of the provinces to individual groups for each region (Figure 5). Then add a button bar or filter to individually select the regions to display (Figure 6). A data tip value can be added so when hovering over the map, the business region will appear.

Now, if the region has custom borders, there is a process for this. To start this process, the user must have Geographic permissions from the admin of the Viya environment (Full admin permissions also work). Once that is completed, they can begin. To start, the user needs to have a shapefile of the region they wish to bring to SAS. The files required for this process to properly run are .shp, .shx, .dbf, and .prj files (Figure 7). These files are used to turn a shapefile into a dataset SAS can read.

Once those files are in SAS, a SAS macro will need to be run. This macro (Figure 8) has <> brackets where the user will need to fill out. The shape file path is the path to the .shp file location. The .shp file must be stored with the other 3 files in the same folder. The ID column is the column with the names of the regions in the shapefile dataset. This file is what maps data to the file once in Visual Analytics by mapping the categorical column that contains the region name and joins it with the shapefile names. If the id column is unknown to the user, I have found a way that if the code is run with the other blanks filled, the code will run with errors but the columns in the .shp file are revealed with the rows. To do this, give the <insert ID Column> a random name and once the name of the column is discovered, replace the ID and rerun the code. The outtable is the name that the SAS dataset will take on after the code is run. The cashost and casport are values found in Manage Environment in the Servers tab, just copy those values over. Lastly, the caslib selection is which library the SAS dataset will be outputted in (Public or casuser typically).

Once the macro has run successfully, the user can navigate to Visual Analytics. This is where the shapefiles are connected to the dataset. Make sure the user’s data containing the region values is included in the report. Then select “New Data Item” in the data pane and “New Geography Item”. Select the region column that has the region names for the “Based on” item. Then select “Geographic data provider”. This is where the new region shapes are created. If the user has created these regions before, they can use a provider in the drop-down menu. In this case a new provider is needed, so click on the three dot icon. Select “New provider” (Figure 9).

The new geographic data provider menu will appear. Enter a Name and a Label; these can be the same or different. This determines how the provider will appear the next time the user wants to use these shapes. Leave Type and Server the same, unless the shapefile macro was saved elsewhere. Select the Library to where the macro in Figure 8 had caslib pointing to (Public in this case). Select the outtable created for the table selection. Select Polygon for geometry. Change the ID column to the value used in id for Figure 8. Then have _seq_, SEGMENT, Y, X for the next 4 options (Figure 10). Lastly, the coordinate space is needed.

Depending on where the .shp was found, it could be a variety of different values. WGS84 is the standard I like to work with but when shapefiles are sourced from outside of the user’s ArcGIS then custom options can be needed. If the EPSG value is known, select coordinate space as custom value and then “EPSG <4-digit number>”. The user may not get it correct on the first try so keep trying different numbers as the EPSG value (that are somewhat close to the estimated value. Googling the value is an option as well). A wrong EPSG value may put the shapes all over the map but as the guesses get closer, the shapes will appear closer to their actual location.

Once this is complete, the provider will be created. Now returning to the geography item page, select ID column as the same as the “Based on” column. Then the regions are complete. Select a geo-region map in the objects pane and select the new geography item as the geography (Figure 11).

The new shapes are properly uploaded into SAS and can be visualized with data. The users now have the freedom to map any territory they prefer and can customize their mapping reports. By combining SAS Viya’s built-in geographic options with the ability to upload custom shapefiles, users can accurately represent business-specific regions that go beyond standard political boundaries. Whether you are grouping existing regions or bringing in fully custom shapes, this process gives you the flexibility to create precise, meaningful maps that better reflect how your organization views and analyzes geographic data.

Learn more

• Mapping data over images
• Utilizing SAS Viya’s Geocoding capabilities for multiple data configurations and languages
• Simulating theme park wait times within SAS Viya, creating a live solution for hospitality operations

Uploading and visualizing custom shapefiles in SAS Viya was published on SAS Users.

Let’s take a look at the absolute minimum amount of code needed to perform hyperparameter autotuning with a gradient boosting model using SAS code.

proc gradboost data=sashelp.iris;
    autotune;
    target species / level=nominal;
    input _NUMERIC_;
run;

Yep. That’s it. It’s literally one extra line: autotune.

When you add this single line, SAS will run it through a genetic algorithm, partition it into a 70/30 train/validation split, run multiple parallel evaluations in a single iteration, and automatically stop after either 50 evaluations, 5 iterations, 10 hours, or stagnation in 4 iterations. Each hyperparameter has pre-configured default bounds and is fully modifiable. If you’re curious as to what these defaults are, check out the documentation for the AUTOTUNE statement in PROC GRADBOOST.

That’s a whole lot of things happening from that one little statement. This gives you a good baseline, and considering how well-tuned the default values are, it may end up being all you need.

Predicting Higgs bosons with SAS

Let’s go back to solving the Higgs boson prediction problem, and this time we’ll do it with SAS code. One thing I love about programming in SAS is how compact the code is for modeling. To show you how little code is needed to solve this problem in its entirety, I’m going to post the whole program below.

filename inpipe pipe "unzip -p /workspaces/myfolder/data/higgs.zip | gunzip -c";
 
%let colnames = signal lepton_pt lepton_eta lepton_phi 
                missing_energy_magnitude missing_energy_phi
                jet_1_pt jet_1_eta jet_1_phi jet_1_btag
                jet_2_pt jet_2_eta jet_2_phi jet_2_btag
                jet_3_pt jet_3_eta jet_3_phi jet_3_btag
                jet_4_pt jet_4_eta jet_4_phi jet_4_btag
                m_jj m_jjj m_lv m_jlv m_bb m_wbb m_wwbb
                ;
 
data higgs;
    infile inpipe dlm=',' dsd;
    input &colnames;
    drop m_:;
run;
 
proc gradboost data=higgs outmodel=low_level_model seed=42 earlystop(stagnation=0);
    partition fraction(validate=0.15 test=0.15 seed=42);
 
    autotune 
        objective=auc 
        searchmethod=bayesian 
        targetevent='1'
        popsize=5
        historytable=higgs_low_level_history
        tuningparameters = (
             ntrees(UB=300) 
             maxdepth(UB=30)
             learningrate(UB=0.1)
        )
    ;
 
    target signal / level=nominal;
    input _NUMERIC_;
 
    output out=low_level_preds role;
run;

That’s a grand total of 38 lines, including some extra whitespace for readability. In those 38 lines, we:

• Define where our file is and how to unpack with unzip and gunzip:

  filename inpipe pipe "unzip -p /workspaces/myfolder/data/higgs.zip | gunzip -c";

• Define our column names and their order:

  %let colnames = ...;

• Unzip, untar, and read in the data:

  data higgs; infile inpipe dlm=',' dsd; input &colnames; drop m_:; run;

Then, in one gradient boosting procedure:

• Perform a repeatable train/validate/test split:

  partition fraction(validate=0.15 test=0.15 seed=42)

• Enable autotuning:

  autotune

• Set our autotuning objective, search method, and target event:

  objective=auc searchmethod=bayesian targetevent='1'

• Create 4 parallel evaluations, with 5 iterations and 5 evaluations per iteration:

  popsize=5

• Save the best model, autotuning history, predictions, and tag the role of each prediction:

  outmodel=low_level_model historytable=higgs_low_level_history output out=low_level_preds role

• Set a few hyperparameter bounds to try because we learned last time that more trees, lower depth, and a lower learning rate are important with this data:

  tuningparameters = ( ntrees(UB=300) maxdepth(UB=30) learningrate(UB=0.1) )

Even though we changed the bounds of a few of our hyperparameters, we are still tuning the rest of the parameters as well. We just gave it some more suggestions.

There are a ton of other autotuning options available. We can go much further than this, including excluding hyperparameters from tuning, adding a second objective, setting a maximum time, using k-fold cross validation, setting a stagnation threshold, and much more.

Not only that, but PROC GRADBOOST handles both classification and regression in only one PROC. You simply tell it what type of target you have, and it sorts out the rest. You’ll find this to be the case for the rest of the machine learning PROCs too, such as Deep Neural Networks and Support Vector Machines. This simplifies the world of models you need to know.

Let’s run this model and see how it compares.

The results

How did we do this time around? Using the SAS autotuning framework, we achieved a test AUC of 0.801 for the low-level model. Let’s put this into perspective with the rest of the models we were against, including our previous SAS model that was tuned with Optuna.

Here’s what all the evaluations looked like:

Overall, impressive results for how little code we needed, and we even got our best result just 9 evaluations in. This shows how well SAS has tuned its hyperparameter autotuning framework, looking at optimal combinations of hyperparameters to test without the end-user trying to find a good starting point for each one.

Going bigger

If you’re ready to scale out with huge data, you don’t need to learn a whole new language. Many SAS modeling procedures automatically change where the calculations happen, bringing massively parallel, multithreaded processing to your data without any extra effort on your part. All you need to do is load your data to CAS and change your input dataset, then SAS handles the rest.
Don’t believe me? Give it a try yourself on SAS Viya with our first example using Iris:

cas; caslib _ALL_ assign;
 
data casuser.iris;
    set sashelp.iris;
run;
 
proc gradboost data=casuser.iris;
    autotune;
    target species / level=nominal;
    input _NUMERIC_;
run;

All we did was load the data into CAS and tell PROC GRADBOOST that our data is no longer on disk, but in CAS. Just like that, the processing is now massively parallel and ready to scale to your demands.

Wrapping it up

We went through two examples of using sasviya.ml’s GradientBoostingClassifier and PROC GRADBOOST, showing that you can get impressive results in either language. You may be wondering which one is better.

Want to know a secret?

They’re both using the exact same engine.

sasviya.ml isn’t some watered down set of algorithms for Python data scientists. Far from it. This is the same high-performance, trusted, battle-tested math that backs other SAS Viya machine learning models. The SAS Viya Python API is designed to be Pythonic and work with other open source packages, letting you seamlessly integrate your favorite packages in the open source ecosystem, like Optuna, with virtually no learning curve.

The flexibility of SAS Viya Workbench gives you the option to run your models in multiple languages while using the same underlying engine. Whether you’re using Python or a PROC, you can be assured that you’re going to get the performance and results that you expect from SAS. The language you use, and how you mix them together, is entirely up to you.

Links

• Previous article: Boost ML accuracy with hyperparameter tuning (with a fun twist)
• Documentation: Overview of Hyperparameter Autotuning in SAS Viya
• UC Irvine Machine Learning Repository - Higgs boson dataset

References

• Whiteson, D. (2014). HIGGS [Dataset]. UCI Machine Learning Repository. https://doi.org/10.24432/C5V312. Licensed under CC BY-SA 4.0.

The afterparty: Hyperparameter autotuning revisited was published on SAS Users.

Mapping in SAS Viya gives the user plenty of options for maps to use. Signing in to ESRI on SAS Viya gives us many more. But what if the map that is needed is not available and is technically not a map at all? Well, not to worry, as there is a solution for that. Mapping on images is a lot like creating shapefiles on regular maps; the main difference is how that map is uploaded to SAS. This solution gives the user full control of what they would like to see in their reports and gives them full customizability for mapping visualizations.

The first step is having an ArcGIS Online account. This account needs to be set up with some credits to use as data storage currency so that the image the user uploads can be saved in the system storage. Once this step is complete, the user must also have a desktop version of ArcGIS Pro, where the maps can be built. Within the desktop application, the user must be connected to their ArcGIS Online account through the sign-in page to ensure everything is connected.

Now the user can begin the process. Once in ArcGIS Pro, a new project must be created. This will bring up a map of the world. In the contents pane, right-click Map and select Add Data. A box will pop up to browse the files, and the user can select the image they wish to use (Figure 1). For this example, the user will be using an image of a stadium.

The image name will pop up below Map on the Contents pane, and a warning will say “Unknown Coordinate System”, which is fine since the user will be specifying their own coordinates for the image. To provide these coordinates, go to the Imagery tab at the top of the application, from there Imagery options should appear (Figure 2).

Right-click on the image name in the contents pane. Select “Zoom to Layer” and the user will be brought to where the picture is on the map (without a coordinate system, the image should originate in the middle of the Atlantic Ocean). In the Imagery tab, select the “Geo Reference” option. Then the system will allow the user to begin geo-referencing the image. The user must now choose where they would like the image to appear on a map. The user must select the “Add Control Points” option in the ribbon. Then the user can select a point on the picture. Here, a notable corner on the image is selected (Figure 3).

Once the initial point is selected, the user must then select a point on the map that this control point connects to (Figure 4).

The image will now be placed over the point in its original orientation (Figure 5).

The user must add another control point to get the image to follow the proper orientation of its place on a map. To add another control point, select the point on the image as a source point and then select another point on the map as a target point (Figure 6).

The image should follow its proper orientation now, but further reference points may be needed to be exact. In my experience, 3-4 is the maximum number of points needed, as the image will start to have distortion and become less accurate.

The image is now mapped and needs to be saved. Right-click on the Map in the Contents pane and select Properties. Give the Map a name, then close the Properties tab. The new name should be reflected where the word "Map" used to be. Right-click the new map name and select “Edit Metadata”. The user should now give the Item a Title, some tags (brief descriptions of the map), and a summary. Select “Apply” in the ribbon and close the metadata page. The user can now upload this image to their ArcGIS Online account. Go to the Share tab and select Web Layer – Publish Web Layer (Figure 7).

Figure 7: Publish Web Layer location

A share page will pop up. Select Layer Type to be Tile and Share with Everyone. Then select Publish. The image will now be uploaded to the ArcGIS Online account.

In ArcGIS Online, go to the My Content page. Find the name of the map that was just created, and the file should say “Tile Layer (hosted)”. Select the map, and an overview of the map will pop up. Go to Settings and scroll to Tile Layer (hosted). This is where the user chooses how detailed the image will be on the map's scale. In Figure 8, World to Country is the default, but depending on the size of the image, the user should change the dropdown from Country. For instance, if it is a map of a building, then go to the size of a small building; if it is a large park select the option that is closest to that size.

Figure 8: Selecting the Visible Range for the image, depending on the size of the image, the user can change how far out it can be seen from viewing the map

Next, do not select Build Tiles. First, select Save below the visible range selector (Figure 9).

Figure 9: Saving the tile

Once saved, select Build Tiles. The tile screen will appear, and once it has finished uploading, select Create Tiles (Figure 10).

Figure 10: Creating the tiles

From there, our tile/image is uploaded to the ArcGIS cloud. To use this in SAS Viya, go into SAS Viya Explore and Visualize. The user must be signed into their ArcGIS Online account from there. If they are not, they can go to their user icon while in Explore and Visualize, select Settings, and select Geographic Mapping, and sign in there. Once signed in, bring a map into the Explore and Visualize workspace. This can be any of the maps in the Objects tab. In the options on the right-hand side, select Maps (Figure 11).

Figure 11: Choosing a map, it will default an Automatic map

The user’s maps will show up under User Tiles here. Select the file folder icon and a list of mapping options become available to the user (Figure 12). Since the user created a tile in ArcGIS Online, the image will be in that folder.

Figure 12: All mapping folders available. The ArcGIS.com folders only appear if the user is signed into their ArcGIS Online account in Viya

When the image is selected, it will populate within the map. Depending on the Visual Range selected in Figure 10, the user may need to zoom to the proper level to see the map. These maps can have shapefiles overlap the image as well. I have added shapefiles to each of the sections of the stadium, so the map is more interactive with data (Figure 13).

Figure 13: The final map result in Visual Analytics using a geo-region map

Another example of the image mapping is in Figure 14, with mapped body sections over a diagram of the human body.

Figure 14: An image of the human body being mapped with custom shapefiles of body sections.

This is how the user can map over top of images. It allows them to customize their mapping interface for full freedom in their report visualizations.

Mapping data over images was published on SAS Users.