16
Oct

A tip for moving content between SAS Viya environments

moving content between SAS Viya environmentsIn a SAS Viya 3.2 environment two types of content can be created: SAS Visual Analytics Reports and Data Plans. For administrators, who may want to manage that content within a folder structure, there are some things to keep in mind. In the current release, both types of content can be moved around in folders, but the objects cannot be copied. In addition, SAS Viya 3.2 supports the promotion of SAS Visual Analytics Reports, but doesn’t support the promotion of Data Plans (support for Plans is coming in SAS Viya 3.3). So, what if I want to copy a report between, say my personal folders, to a production folder?

If you want copy a Report or Data Plan within an environment there is an easy way. When the object is open in edit mode you can do a Save As to save a copy to a different location in the folder structure.

Between environments, Reports can be exported and imported using the SAS Visual Analytics, when you are editing your content (Report or Data Plan) you can access a “diagnostics” window. The diagnostics window will show you the json (or xml) used to render the Report or Plan. To enter the diagnostics window use the keystrokes:

  • ctl+alt+d for SAS Visual Data Builder.
  • ctl+alt+b for SAS Visual Analytics.

In the steps below I will use the diagnostics window to save a Data Plan so that it can be loaded to a different SAS Viya Environment. The steps for a SAS Visual Analytics report are very similar.

In SAS Visual Data Builder when editing your Data Plan select ctl-alt-d to open the SAS Visual Data Builder Diagnostics window. The source tab of the window shows the json that will render the data plan.

Click Save to save the json to a text file and close the dialog. The json file will be saved in the browsers default downloads folder.

Copy the saved text file to a location accessible to the SAS Viya environment where you want to import the plan. In that environment, open Data Builder and click New to open a new Data Plan.

Click ctl-alt-d on the empty data plan and cut and paste the json from your text file replacing the json in the diagnostics window.

Click Parse to check the json.A message should be displayed indicating that the  “plan text was parsed successfully.”  Once you have parsed the text, click Run and the plan is loaded into SAS Visual Data Builder.

In SAS Visual Data Builder, select Save As and save the plan to any location in the folder structure.

The assumption with this approach is that the data is available in the same location in both environments.

You can do much the same with SAS Visual Analytics reports. The key-stroke is ctl-alt-b to open the SAS Visual Analytics Diagnostics window.  You can see the report xml or json on the BIRD tab.

To copy a single report between environments, you can select json and then save the json to a file. In the target environment open a new report, paste the json in the BIRD tab, parse and load and then save the report to a folder. This can be a useful approach if you want to relocate a report to a different location in your target environment. The transfer service currently will only import reports to the same folder location in the target that they are located in the source environment.

I hope you found this tip useful.

A tip for moving content between SAS Viya environments was published on SAS Users.

25
Sep

A review of the options available for upgrading a SAS 9 deployment

With the fifth maintenance release of SAS 9.4 (SAS 9.4M5) now available, it seems like a good time to get a refresher on some of the ways you can upgrade your existing SAS deployments to the latest release. Among several benefits, SAS 9.4M5 provides closer integration with the CAS in-memory runtime engine in SAS Viya so it’s something you might want to consider.

There are three ways you can upgrade a SAS Deployment, they are illustrated in the diagram below. Let’s take a look at each one:

Upgrading a SAS 9 deployment

Automated Migration

Automated migration consists of creating a new SAS deployment from an existing SAS Deployment using the automated migration tools the SAS Migration Utility and SAS Deployment Wizard. The automated migration tools and process are designed to create a target deployment that preserves the content and configuration information from the source. These tools require an all-at-once approach, and provide limited options for making changes to the deployment during the upgrade. The automated migration tools support a like-for-like transition—the operating system family and the distribution of SAS components must be the same in the source and target environments.

Deploy new and Promote

Promotion is a related concept to migration; promotion is the process of copying selected metadata and associated content within or between SAS Deployments. To upgrade using promotion, create a new out-of-the-box SAS deployment and use the export/import functionality to move the content from the old deployment. The promotion framework is designed to allow you to selectively move content from one deployment to another. Depending on the release of your source deployment there are limits to the content that can be exported using promotion; however, this option offers the most flexibility in changing the deployed topology, operating system and transitioning in stages.

Update-in-Place

Update-in-Place is the process of upgrading an existing SAS Deployment to apply maintenance or add and update SAS products. The update modifies the existing deployment rather than creating a new deployment. Update-in-place is only supported within a major SAS release. For example, you can use update-in-place to update a SAS 9.4 deployment to maintenance 4 or maintenance 5, however you cannot use update-in-place to transition from SAS 9.3 to SAS 9.4.

Considerations when Deciding on an Approach

Automated Migration

  • Automated migration moves a whole system, configuration and content, you cannot move only part of a system.
  • The tools support migration from (n-2), so the earliest release you can migrate from is currently SAS 9.2.
  • Individual SAS Products and solutions may have additional baselines for migration.
  • During a migration you cannot change your:
    • Operating system family.
    • Software Topology (the distribution of the SAS components in the environment).

Deploy new and Promote

  • Deploy New and promote creates a new deployment and moves content into it.
  • The target system can be a different topology and operating system from the source.
  • The tools support promotion from (n-2), so the earliest release you can promote from is currently SAS 9.2.
  • Content can be transitioned in stages.
  • Not all content is supported by the import and export wizards and batch tools (e.g., dashboard content cannot be promoted between releases and portal content requires execution of a command line tool).

Update-in-Place

  • Update-in-Place can only be done within the same major SAS release.
  • Updates operate on a whole deployment, you cannot selectively update products.
  • Maintenance updates do not preserve the source environment because maintenance releases:
    • are applied to the existing environment.
    • are cumulative (including hotfixes).
    • cannot be uninstalled, e.g. you cannot uninstall M2 to get back to M1.
  • Adding products to a Deployment will require a second pass through the SAS Deployment Wizard (update and then add).

Summary

I would encourage you to consider your target SAS 9.4 deployment as a new house.

Using automated migration you would move the house. Take the whole house off its current foundation. Move the house, contents and all, to a new foundation.

  • The Layout of the house remains the same.
  • Everything in the house moves at one time.
  • Anything outside the house does not move.

Using deploy new and promote you can selectively move the content of your house to a whole new house. You can leave your junk behind. Your new house:

  • Must be built before you move in.
  • Can be constructed any way you want.

No matter how hard you try you cannot move all content.

With update-in-place you have a renovation project of your existing house. However, if your house is old, you cannot or may not want to renovate it. Plus, if you mess up the renovation then your existing house is broken.

You can find the documentation on upgrading in a variety of places.

A review of the options available for upgrading a SAS 9 deployment was published on SAS Users.

7
Sep

How do I access the Premium Esri Map Service for my SAS Visual Analytics reports?

In SAS Visual Analytics 8.1, report creators have the ability to include drive-distance and drive-time in their geographical maps, but only if their site has an Esri ArcGIS Online account and they have valid credentials for the account.

In the user Settings for SAS Visual Analytics Geographic Mapping 8.1 release, there are three choices for selection of a geographic map provider.  The map provider creates the background map for geo maps and for network diagrams that display a map.

The map provider options are:

  • OpenStreet Map service, hosted at SAS.
  • Esri ArGIS Online Services, which only requirFinale acceptance of the terms and conditions.
  • Esri premium services, which requires a credential validation.

If Esri premium services is selected, there is an additional prompt for valid credentials, and you must still accept the Esri ArcGIS Online Services terms in order to select the premium services checkbox.

It’s also worth pointing out here, that even if you have Esri premium credentials, in order for these credentials to be validated in SAS Visual Analytics, you must also be a member of the ESRI Users custom group.  Users can be added to this group in SAS Environment Manager, as shown below.

Note that without the Esri ‘premium’ service and validated credentials, when you right-click and Create geographic selection in your report map, you are only able to select the Distance selection, which displays the radial distance for the selection point.

With premium services in effect, you can also select drive-time or drive-distance.  An example of a drive-time selection is shown here.  Drive-time creates an irregular selection based on the distance that can be driven in the specified amount of time.

A drive-distance example is shown below.  Drive-distance creates an irregular selection based on the driving distance using roads.

When selecting drive-time or drive distance, you can also add breaks to show, as in the example below, the 5-mile distance, the 10-mile distance, and the 15-mile distance on the maps.

It’s also worth pointing out, that if a viewer of the report has not had Esri premium credentials validated, the viewer will be unable to view the drive-distances and drive-time features.  The settings for users of the report viewer are also stored in the Report Viewer Geographic Mapping user settings.

If a user is adding a connection to the server in SAS Mobile BI 8.15 and their account is a member of the Esri Users group, they will be prompted for their Esri premium credentials when adding the server connection:

I hope you’ve found this post helpful.

How do I access the Premium Esri Map Service for my SAS Visual Analytics reports? was published on SAS Users.

18
Aug

Making the sas.servers script look pretty

If you are a SAS administrator managing an environment on UNIX or z/OS, you must use the sas.servers script on a regular basis. As you know, one of its uses is to display the current status of all servers. Is the output accurate? Absolutely. Is it easy to read? Relatively. Is it visually attractive? Not so much.

Human beings are visual creatures. Conventional wisdom says that a picture speaks a thousand words. However, I am not using images to improve the output, but another powerful tool: color. According to this Xerox paper, color captures attention and enhances productivity. It can improve search time, reduce errors, and increase comprehension. As a result, this blog post provides the steps for applying color and an easy-to-read layout to make the sas.servers script look cute and even fun!

Preliminary Steps

Before we begin, it is important to give you some recommendations:

  1. Stop all SAS services.
  2. Backup the files: sas.servers, sas.servers.mid and sas.servers.pre
  3. Apply these changes to a Development or Testing environment.

As a matter of fact, I consider steps 1 and 3 as optional. This script is only used by the SAS platform to start/stop/restart or check the status of the servers. Moreover, if you follow all steps carefully, you can apply these changes safely in a Production environment. In contrast, step 2 is relevant; it is always a good practice to backup essential files before modifying them. In case you need to rollback, you can restore them easily and quickly.

Things to Consider

The About the sas.servers Script section from the SAS 9.4 Intelligence Platform: System Administration Guide provides a caution message: "You should not directly update the sas.servers script." In our case, the type of customization we are about to perform requires a manual update. Don't worry, your script is in good hands.

Furthermore, if you ever need to update the sas.servers script because you want to add/remove a server, you have to run the generate_boot_scripts.sh script to regenerate this file. After doing so, you can lose all the changes made in this post. Keep this in mind, so you can backup the current files before attempting this task.

Easy-to-read Layout

Let's jump into the details. First of all, let's define the new layout of the desired output. Grab your favorite text editor. I use Notepad++ at the office, and Sublime Text at home. Go to your /SASCONFIG/Lev1/ directory and run a regular status command as the sas user. Assuming you followed the preliminary steps and depending on the products installed and the number of SASServers deployed, you should get a similar output:

./sas.servers status
SAS servers status:
SAS Web Infrastructure Data Server is NOT up
SAS Metadata Server 1 is NOT up
SAS Object Spawner 1 is NOT up
SAS DIP Job Runner 1 is NOT up
SAS Information Retrieval Studio Server is NOT up
SAS JMS Broker is NOT up
SAS Cache Locator Service ins_41415 is NOT up
SAS Web Server is NOT up
SAS Web App Server SASServer1_1 is NOT up
SAS Environment Manager is NOT up
SAS Environment Manager Agent is NOT up

Copy that output, except the first line, and paste it into your text editor. Here you can modify the output according to your taste. What I did was to identify the longest line, which is SAS Information Retrieval Studio Server, then I added four spaces to the right and substituted the legend is NOT up for [DOWN]. Likewise, I applied these changes to the rest of the servers, removed the instance number, and kept them all aligned:

SAS Web Infrastructure Data Server         [DOWN]
SAS Metadata Server                        [DOWN]
SAS Object Spawner                         [DOWN]
SAS DIP Job Runner                         [DOWN]
SAS Information Retrieval Studio Server    [DOWN]
SAS JMS Broker                             [DOWN]
SAS Cache Locator Service ins_41415        [DOWN]
SAS Web Server                             [DOWN]
SAS Web App Server SASServer1_1            [DOWN]
SAS Environment Manager                    [DOWN]
SAS Environment Manager Agent              [DOWN]

I chose the pair [ UP ]/[DOWN] to reflect the status because I wanted the look and feel from CentOS 6 boot process. If you are/were a CentOS 6 user, you can remember that the services display the legends: [ OK ] or [FAILED] when booting. You are free to use other alternatives such as ACTIVE/INACTIVE or perhaps RUNNING/STOPPED with or without brackets. Now that the layout is finished, let's move on to the color department.

All You Need Is Color

The fun finally arrived. Let's integrate the layout into our three scripts and add the main ingredient: color!

Again, I am assuming at this stage that you already backed up the files: sas.servers, sas.servers.mid, and sas.servers.pre. Next, open the sas.servers file with your vi editor and add this code anywhere at the top, below the block of comments:

#*****
# Custom Colors for status command
# RED   for [DOWN]
# GREEN for [ UP ]
# NC    for No Color
#*****
RED='e[31m'
GREEN='e[32m'
NC='e[0m'

These lines create three variables with three different color codes: a RED variable with code 31, a GREEN variable with code 32, and a NC variable with the default color code. The definition of these variables is optional but recommended, since they help you debug problems or change colors more easily. If you prefer to use different colors or attributes, you can play with the codes as shown in Bash tips: Colors and formatting.

Considering that the sas.servers script does not contain all servers, you have to add the same code to sas.servers.mid and sas.servers.pre files.

First Example

Now that we have defined the three variables in all the necessary files, let's use them. I'll show you how to apply them to a couple of servers, and then you can replicate it to the rest. The first one is the SAS Metadata Server. Open the sas.servers script again and find these lines:

# SAS Metadata Server
SASMETA_WONT_START_OTHERS="The remaining SAS servers will NOT be started as a result."
 
SASMETA1_IS_UP="SAS Metadata Server 1 is UP"
SASMETA2_IS_UP="SAS Metadata Server 2 is UP"
SASMETA3_IS_UP="SAS Metadata Server 3 is UP"
SASMETA4_IS_UP="SAS Metadata Server 4 is UP"
SASMETA5_IS_UP="SAS Metadata Server 5 is UP"
 
SASMETA1_IS_DOWN="SAS Metadata Server 1 is NOT up"
SASMETA2_IS_DOWN="SAS Metadata Server 2 is NOT up"
SASMETA3_IS_DOWN="SAS Metadata Server 3 is NOT up"
SASMETA4_IS_DOWN="SAS Metadata Server 4 is NOT up"
SASMETA5_IS_DOWN="SAS Metadata Server 5 is NOT up"

Since I have a single Metadata Server instance, the only meaningful variables are SASMETA1_IS_UP and SASMETA1_IS_DOWN. Delete their values, copy the correct string from your text editor, and paste it in both variables. Fix them accordingly:

SASMETA1_IS_UP="SAS Metadata Server                        [ UP ]"
#more instances
 
SASMETA1_IS_DOWN="SAS Metadata Server                        [DOWN]"
#more instances

The final touch is to give color to our script. Use the GREEN and RED variables for the UP/DOWN statuses. It is important to include the NC variable at the end to remove all attributes:

SASMETA1_IS_UP="SAS Metadata Server                        [ ${GREEN}UP${NC} ]"
#more instances
 
SASMETA1_IS_DOWN="SAS Metadata Server                        [${RED}DOWN${NC}]"
#more instances

Second Example

The process is the same for all the servers defined in the sas.servers script. For the other two scripts it is a little different, but still quite easy. I am going to use the SAS Web Infrastructure Data Server as the second example. Open the sas.servers.pre script and look for the server_status() function. Pay attention to these lines:

       if [ $? -eq 0 ]; then
          # Server is already running
          echo "SAS Web Infrastructure Data Server is UP"
       else
          echo "SAS Web Infrastructure Data Server is NOT up"
       fi
    }
    else
      echo "SAS Web Infrastructure Data Server is NOT up"

A subtle difference from the previous example is the echo command. In the sas.servers script, there is a logmsg() function that uses the "echo -e" command behind the scenes. In this case, we have to explicitly add the -e option to enable the interpretation of backslash escapes. Let's also integrate the color and layout:

          echo -e "SAS Web Infrastructure Data Server         [ ${GREEN}UP${NC} ]"
       else
          echo -e "SAS Web Infrastructure Data Server         [${RED}DOWN${NC}]"
       fi
    }
    else
      echo -e "SAS Web Infrastructure Data Server         [${RED}DOWN${NC}]"

At this point, with the above examples, you should have a solid idea about the required changes to accomplish our goal. Now it is your turn to apply them to the rest of the servers.

Finished Product

If you followed this article in detail and performed the steps in all the required servers, your output should resemble mine:

Get the green light by running the start command:

Final Thoughts

I am a visual person with a curious mind. One of the things I like is to customize the tools I use the most, so I decided to make the sas.servers script output a little more attractive to my eyes. I hope you liked the result. If you are still not sure whether to implement this idea or not, let's suppose there are some problems with a couple of servers in your environment and they stop running. Which output would you rather look at? Which one is easier to spot an issue? Let me know your thoughts in the comments below, or even better you can share your creative outputs!

Making the sas.servers script look pretty was published on SAS Users.

17
Aug

SAS Viya sharing credentials for database access

SAS Viya deployments use credentials for accessing databases and other third-party products that require authentication. In this blog post, I will look at how this sharing of credentials is implemented in SAS Environment Manager.

In SAS Viya, domains are used to store the:

  • Credentials required to access external data sources.
  • Identities that are allowed to use those credentials.

There are three types of domains:

  • Authentication stores credentials that are used to access an external source that can then be associated with a caslib.
  • Connection used when the external database has been set up to require a User ID but no password.
  • Encryption stores an encryption key required to read data at rest in a path assigned to a caslib.

In this blog post we will focus on authentication domains which are typically used to provide access to data in a database management system. It is a pretty simple concept; an authentication domain makes a set of credentials available to a set of users. This allows SAS Viya to seamlessly access a resource. The diagram below shows a logical view of a domain. In this example, the domain PGAuth stores the credentials for a Postgres database, and makes those credentials available to two groups (and their members) and three users.

How does this work when a user accesses data in a database caslib? The following steps are performed:

1.     Log on to SAS Viya using personal credentials: the user’s identity is established including group memberships.

2.     Access a CASLIB for a database: using the user’s identity and the authentication domain of the CASLIB, Viya will look up the credentials associated with that identity in the domain.

3.     Two results are possible. A credential match is:

  • 1.     Found: the credentials are passed to the database authentication provider to determine access to the data.
  • 2.     Not found: no access to the data is provided.

To manage domains in SAS Environment Manager you must be an administrator. In SAS Environment Manager select Security > Domains. There are two views available:  Domains and Credentials. The Domains view lists all defined domains. You can access the credentials for a domain by right-clicking on the domain and selecting Credentials.

The Credentials view lists all credentials defined and the domains for which they are associated.

Whatever way you get to a credential, you can edit it by right-clicking and selecting Edit. In the edit dialog, you can specify the Identities (users and groups) that can use the credential, and the User ID and Password of the credential.  Note that only users who are already listed in the Identities field will be able to edit this field, so make sure you are in this field (directly or through group membership) prior to saving.

To use an authentication domain, you reference it in the CASLIB definition. When defining a non-path based CASLIB you must select a domain to provide user credentials to connect to the database server. This can be done when creating a new CASLIB in SAS Environment Manager in the Data > Libraries area.

If you use code to create or access your caslib, use the authenticationdomain option. In this example, we specify authenticationdomain in the table.addcaslib action.

If a user is not attached to the authentication domain directly, or through a group membership, they will not be able to access the credentials. An error will occur when they attempt to access the data.

This has been a brief look at storing and using credentials to access databases from SAS Viya. You can find  more detail in the SAS Viya Administration Guide in the section titled SAS Viya sharing credentials for database access was published on SAS Users.

28
Jul

Controlling Stored Process Execution through Request Initialization Code Injection

Recently, I was working with a client who had a unique problem. He needed a way to cancel a stored process from executing in cases where the stored process wasn’t registered to the matching Metadata folder-structure for its selected server context. For example, if a stored process was stored under the DEV folder-structure in Metadata but attempted to be run on the PROD server context, the execution of the stored process would then need to be canceled and alert the user of the error.

Fortunately, this type of behavior with stored processes can be achieved by injecting SAS code that runs before the stored process executes via Request Initialization of the Logical Stored Process Server.

In this example, the client has two logical environments that reside within a single physical/metadata environment. The two logical environments are DEV and PROD. The client doesn’t want stored processes in DEV to run on PROD-associated servers.

Preliminary requirements

A stored process registered on one logical environment (e.g., DEV) won’t run on the server context of another logical environment (e.g., PROD).

The following steps show you how to set up a Request Initialization for a Logical Stored Process Server in order to cancel a stored process from executing on the PROD server, if it isn’t stored in PROD in metadata.

1) Write the desired injection code. In this case, the code checks if the stored process is registered with PROD and then either cancels the stored process or proceeds with normal execution.

/* This code checks macros variables populated by the currently executing stored process to discover the path in metadata where the currently executing stored processes is located. It then compares this metadata path with the expected path for the server context this code will be injected into. For example, the redacted line below might say “PROD” to signify the top-level. It cancels if the path is not a match; otherwise, execution continues normally. */
%macro CheckProdStpRegistration();
	%let stp_path =;
	%if %symexist(_METAFOLDER) %then %let stp_path = &_METAFOLDER;
	%else %if %symexist(_PROGRAM) %then %let stp_path = &_PROGRAM;
	%else %do;
		%let stp_path = INVALID_REGISTRATION;
		%put ERROR: The macro variables _METAFOLDER and _PROGRAM are not 
      defined. Cannot determine stored process registration.;
	%end;
 
	/* Check top-level filepath is what is expected in metadata PROD folders. */
%if ^(%scan(&stp_path,1,%str(/)) = Logical
AND %scan(&stp_path,2,%str(/)) = PROD) %then %do;
		%put ERROR: Only stored processes registered in PROD can be run on an 
      PROD-based Stored Process Server. Canceling the stored
      process execution.;
 
		/* Cancel the stored process from running. */
		data _null_;
			abort cancel;
		run;
	%end;
%mend CheckProdStpRegistration;
 
%CheckProdStpRegistration();

In this example, the code checks the macro variables that are populated with running a stored process. After retrieving the metadata path where the stored process is stored, the code then checks that the first and second parts of the path are equivalent to “Logical/PROD”. This matches the logical PROD environment from above.

2) Now that we have our code, we can set it to run before every executed stored processes via a Request Intialization under the Logical Stored Process Server options.

NOTE: After changing this property, you’ll have to refresh the Object Spawner so that the changes take hold.

In this example, we go into the properties for the Logical Stored Process Server associated with the PROD server context. In the properties, you can find the Request Initialization under the Options tab > Set Server Properties > Request tab. You then simply provide the path to the SAS program created in step 1.

3) Test a stored process located metadata under the DEV folder structure and test a stored process in metadata located under the PROD folder structure. Ensure the stored process is set to execute against the Application server that the Request Initialization code was applied to (e.g., the PROD server context).

In this example, the Application Server selected is the one that the Request Initialization code was applied to. The stored process can then just be moved from one location to another in order to test the process: to ensure that a stored process not registered in PROD cannot be run on the PROD Logical Stored Process Server.

You should not that the part of the code that is essential to canceling the execution of a stored process is the “abort” statement with the “cancel” option. There is no other way to gracefully terminate a stored process’s execution. Other methods will either allow the stored process to still run or cause errors that can affect the current session and mislead the end-user.

/* Cancel the stored process from running. */
		data _null_;
			abort cancel;
		run;

In this example, the ‘abort cancel’ statement/option is shown. It simply just needs to run in a ‘null’ data-step in order to cancel the upcoming stored process execution.

I hope you found this tip helpful. Feel free to leave a question or comment in the space below.

Controlling Stored Process Execution through Request Initialization Code Injection was published on SAS Users.

30
Jun

Using multiple server contexts in SAS Visual Analytics

As a technical consultant for SAS, I have the privilege of meeting with SAS customers, learning more about how they use our software, and then helping them solve their problems. Recently, a client of mine was having trouble finding a way to implement the use of multiple application servers in SAS Visual Analytics 7.3 based on what business unit a user is a part of. Guessing that some of our SAS Visual Analytics Administrators may have the same question, I thought I’d share how we solved his problem.

The outline below is the order of operations of how a server context is selected. The example provided in the screenshots is how you would control access so that user requests will only be sent through the appropriate business unit server.

Preliminary Requirements

  • The Server is registered with the job execution service.
  • The Server is visible to the requesting user.

Assuming that all servers are registered with the job execution service the following steps are how an application server would be selected:

Step 1: The server associated with the target LASR library will be used. If the server is not visible to the user, proceed to step 2.

Figure 1: In this example the server context associated with the target library is SASApp which the user is denied access to in the server context permissions

Step 2: The suite-level default server defined in the SAS Visual Analytics configuration properties at “va.defaultWorkspaceServer” will be used. If the server is not visible to the user, proceed to step 3.

Figure 2: In this example the configuration property is also set to SASApp which the user is denied access to in the server context permissions

Step 3: Lastly, use any server that is registered with the job execution service and visible to the requesting user.

Figure 3: In this example the BU server context would end up being chosen because it is the only context that the user has permission to access

Some additional Info to Keep in Mind

  • The preferences in the administrator and data builder tabs allow the forced used of a specific server by opting out of automatic selection. These preferences can be separately set and one does not affect the other.
  • In SAS Visual Analytics Explorer, the pooled workspace server is used to populate the available data to import field, and the workspace server is used to perform the actual importing.

Figure 4: The pooled workspace server is denied access so the import data area will not be populated

I hope you found this blog helpful. Please feel free to leave a question or comment below.

Using multiple server contexts in SAS Visual Analytics was published on SAS Users.

29
Jun

New rules for authorization in SAS Viya

In this blog post I’d like to explore how to create a custom group in SAS Viya to restrict access to functionality. To illustrate my points, we will create a report developers custom group and ensure that only users of that group can create reports and analysis in SAS Visual Analytics.

What a user or group can do (and see) is controlled by rules. A rule is a composite of authorization elements including:

  • Principal: user or group.
  • Target: a resource for example a service, folder or report.
  • Permissions: type of access for example read or write.
  • Setting: indication of whether access is provided, for example grant or prohibit.

The target of a rule is identified using a uniform resource identifier (uri). The uri can represent a folder, content such as a report or data plan, or functionality and features such as being able to import data. Here are some examples of uri’s in SAS Viya:

  • Data Plan: /dataPreparationPlans/plans/810e2c6b-4733-4d53-94fd-dfeb4df0de9e
  • Folder: /folders/folders/e28e35af-2673-4fc7-81fa-1a074f4c0de9
  • Functionality: /SASVisualAnalytics/**

In our example, we will look at restricting access SAS Visual Analytics for a subset of users. In SAS 9.4 this would have been accomplished using roles and capabilities. In SAS Viya, we will:

  • Create a custom group.
  • Govern that groups access to functionality using rules.

Create a New Custom Group

In SAS Environment Manager, as an administrator (only administrators can manage users and groups) select Users > Custom Groups > New.

In the new custom group screen give the group a name, a unique id and a description. We will call our group Report Developers.

After the new group is created, click the edit button to add new members to the group. You can add users or other groups as members of the new group.

Change the Rules so that Only Report Developers can Access the SAS Visual Analytics Application

Now that we have a new group called Report Developers, the next step is to create or update the rule that determines who can access this functionality. First, we will look at what rules currently apply to SAS Visual Analytics.

In SAS Environment Manager select the Security menu item and select the Rules view.

Select Filter by: ObjectURI and enter SASVisualA in the search box.

The second rule listed is the one we are interested in. Notice that URI ends with /**.  URI’s can end with /* or  / **.  An objectUri that includes the /** suffix affects access to all descendant functionality. For example, the /SASVisualAnalytics/** means all functionality in the SAS Visual Analytics application.

Select /SASVisualAnalytics/** and click the Edit icon.  The attributes show that this rule determines who can use SAS Visual Analytics. Currently you’ll see:

  • Grants Read access
    • to /SASVisualAnalytics/** and all its descendent functionality
      • to all authenticated users.

The rule works because the general authorization system implicitly disallows any access that is not granted. The current rule overrides the implicit deny to allow authenticated users to access SAS Visual Analytics. We will edit the rule and change the principal from Authenticated Users to ReportDevelopers.

In the edit rule screen under Principal, select ReportDevelopers.

The impact of the change is that now only users who are members of the Report Developers group can access the Visual Analytics application to create reports.

To test this, you can logon as a user who is not a member of the group. Those users will be able to navigate to reports and open then using the report viewer, but they will not be able to access SAS Visual Analytics to create new reports.

That is a quick look at using custom groups and rules to dictate what users can do in SAS Viya. There is much more detail on these topics in the SAS® Viya 3.2 Administration Guide:

New rules for authorization in SAS Viya was published on SAS Users.

29
Jun

The SAS Visual Analytics 8.1 Data Pane: Creating Calculations and Aggregations

In my last blog, we examined the data pane in SAS Visual Analytics 8.1. That blog discussed how to have the data pane display the data items of your active data source, and how to perform tasks such as viewing measure details, changing data item properties, and creating geographic data items, hierarchies, and custom categories.  In this blog, we’ll look at creating new calculated data items and calculated aggregations.

If you recall, l you display the Data pane in the Visual Analytics interface by clicking the Data icon on the left menu.

A calculated data item is a new data item created from existing data by using an expression.

  • Calculations are performed on un-aggregated data—the expression is evaluated on each row before aggregations are calculated.
  • Calculated data items can accept parameters.
  • A hierarchy can contain calculated category data items.
  • Calculated data items can be changed to geography data items and used in geo maps.

You can create a derived calculation from a category or measure data item by right-clicking on the data item and selecting Create calculation from data item.

For a category data item, you can create a distinct count, count, or number missing. Creating a derived calculation from a category data item:

For a measure data item, you can create a percent of total, or a periodic calculation based on one of your date data items. Creating a derived calculation from a measure data item:

Notice that in both cases, the new data item is an aggregation, so the new item will appear under the Aggregated Measure category in the data pane.

Note:  In order to use the periodic calculation types, your selected data item must include the year.

You can also edit these new data items by right-clicking on the data item and selecting Edit. Editing a derived calculation:

There is now a single interface for creating calculated data items of type Numeric, Character, Date or Datetime or Aggregated measures.

  • This interface provides both Visual mode and Text mode for viewing and editing the expression.
  • You can drag and drop data items or parameters and operators onto the expression in either mode.
  • In text mode, you can also type in your expression.

Creating a calculated data item or aggregated measure:

Specifying the calculation result type and format:

Some notes for using operators in calculations and aggregations:

  • Operators are provided for both calculations and aggregations.
  • You can expand and collapse each category of operators.
  • If you add an Aggregated operator to an expression, the result type will be changed to Aggregated Measure.
  • You cannot have nested aggregations in an expression.You also have access to periodic operators and simple and advanced aggregated operators for calculation aggregations.

In the same interface, you have access to simple and advanced numeric operators, simple and advanced text operators, along with boolean, date and time, and comparison operators for your calculations.

You also have access to periodic operators and simple and advanced aggregated operators for calculation aggregations.

The most important point to remember in using this interface is to think ahead as to whether you are creating a calculation (operating on each row) or an aggregation (operating across rows) and specify the data type and format before you begin to drag and drop data items and operators.  The default data type is Numeric, but if you add an aggregation operator, the type will automatically switch to Aggregated Measure.

Remember that you also create calculated items of character, date, and datetime data types–and you can choose from a list of date and datetime formats for those data types.

The SAS Visual Analytics 8.1 Data Pane: Creating Calculations and Aggregations was published on SAS Users.

17
Apr

How LASR servers are started from SAS Visual Analytics Administrator

In this post, I will explain how LASR Servers (both Distributed and Non-distributed) are started from the SAS Visual Analytics Administrator application. We will also look at one particular issue and I will provide you with more details to understand the situation and two strategies to address this issue.

When you start a LASR Server from the Visual Analytics Administrator application, the system processes your request in slightly different ways depending on whether you are starting a distributed or non-distributed LASR Server.

What happens in the background for a distributed LASR Server?

1.     The administrator starts a LASR Server from the Visual Analytics Administrator application.

2.     The Visual Analytics Administrator application generates the required code and sends it to the JES to be executed on the SAS Visual Analytics Root Node.

3.     The JES invokes the SAS Object Spawner on the Visual Analytics Root Node.

4.     The SAS Object Spawner initializes a SAS Workspace Server session.

5.     A client connection is established between the JES and the SAS Workspace Server session.
The JES sends the distributed LASR Server startup code generated in step 2, and the SAS Workspace Server session executes it.

6.     As soon as the distributed LASR Server startup code is executed, a distributed LASR Server instance is created. This instance is independent from the SAS Workspace Server session.
After the distributed LASR Server startup code executes, the SAS Workspace Server session, and the client connection drop down. But the LASR Server instance is up and persistent until the administrator stops it.

What happens for a non-distributed LASR Server?

1.     The administrator starts a LASR Server from the Visual Analytics Administrator application.

2.     The Visual Analytics Administrator application generates the required code and sends it to the JES to be executed on the SAS Visual Analytics Root Node.

3.     The JES invokes the SAS Object Spawner on the Visual Analytics Root Node.

4.     The SAS Object Spawner initializes a SAS Workspace Server session.

5.     A client connection is established between the JES and the SAS Workspace Server session.
The JES sends the non-distributed LASR Server startup code generated on step 2, and the SAS Workspace Server session executes it.

6.     As soon as the non-distributed LASR Server startup code is executed, a non-distributed LASR Server instance is created. This instance is dependent on the SAS Workspace Server session.
After the distributed LASR Server startup code executes, the SAS Workspace Server session, and the client connection become persistent until the administrator stops the non-distributed LASR Server.
The SAS Workspace Server session and the client connection are required for the non-distributed LASR Server to be up and persistent.

Potential non-distributed LASR Server issue

The client connection between the JES and the SAS Workspace Server session in non-distributed deployment is crucial. This connection has to be persistent during the non-distributed LASR Server lifetime. As soon as the JES or SAS Workspace Server session goes down, the client connection is broken and the non-distributed LASR Server will go down as well. And, its data become unavailable.

If administrators manage their SAS non-distributed LASR Servers from the SAS Visual Analytics Administrator web application, this will create a dependency between the non-distributed LASR Servers and the middle tier - more specifically with the SASServer1_1 instance (the sas.wip.soapservices application). This dependency does not exist for distributed LASR Servers.

When the dependency exists, each time the middle tier or the SASServer1_1 instance is down, all non-distributed LASR Servers that were managed using the SAS Visual Analytics Administrator will go down automatically because the client connection to the non-distributed LASR Server is broken and its associated SAS Workspace Server session will go down.

This issue will also appear if the network connection between the Middle Tier and the SAS Visual Analytics Root Node is broken. This will break the client connection and terminate the SAS Workspace Server session(s) and their associated non-distributed LASR Server(s).

How can we prevent the issue?

I can think of at least two techniques you can use to prevent the dependency of your non-distributed LASR Servers upon your middle-tier:

  • Start your non-distributed LASR Servers from a SAS program.
  • Configure your LASR Server to start using the AutoLoad facility.

Start your non-distributed LASR Server from a SAS program

Here is a sample program that you might use to start a non-distributed LASR Server:

/* Start the LASR Analytic Server by defining the LASR library*/
libname LASRLIB SASIOLA 
        startserver  host="sasserver01.race.sas.com" port=10013
        signer="sasserver05.race.sas.com:7980/SASLASRAuthorization";
 
/* Keep the SAS session up until SERVERTERM received */
proc vasmp;
   serverwait  port=10013;
quit;

 

This program could be scheduled or set as a service under UNIX or Windows to be executed as soon as SAS Visual Analytics is started/restarted. Whichever strategy you use, you will want to have the code run after these services are up and available:

The SAS Metadata Server.
The Object Spawner on the SAS Visual Analytics Root Node.
The SASLASRAuthaurization service on the Middle Tier:

Start the non-distributed LASR Server Using the AutoLoad capability

AutoLoad runs as a periodic scheduled task. In the standard configuration, a new run of AutoLoad is started every 15 minutes.
AutoLoad periodically scans the contents of a designated host directory, which is referred to as the AutoLoad data directory or drop zone.
AutoLoad will automatically start the associated SAS LASR Server, if it is not yet started.

If you do not already have a LASR library configured with AutoLoad, you will need to use the SAS Deployment Manager application to configure an AutoLoad directory.

In Administration Tasks, choose Configure an AutoLoad Directory for SAS Visual Analytics. And follow the instructions.

Once you have AutoLoad setup, you must make sure certain LASR Library Extended Attributes are set correctly to ensure that the AutoLoad process will automatically start your LASR Server. You will want to set/verify the following attributes for the LASR library:

  • To enable the LASR Server AutoStart only:

  • VA.AutoLoad.AutoStart: YES to indicate that you want the associated LASR Server to be started if it is not already running.
  • VA.AutoLoad.Enabled: YES to enable the AutoLoad process for the Library.
  • To enable the LASR table(s) AutoLoad (optional):

  • VA.Default.MetadataFolder: to relocate the table(s) metadata registration against a specific metadata folder.
  • VA.Default.Location: to specify the location of the table directory at OS level.
  • VA.Default.Sync.*: to manage the table(s) from the VA.Default.Location.

On your SAS Visual Analytics machine, you have to:

  • Set the appropriate security against the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef] to be sure that the appropriate LASR Server administrator will be allowed to manage it.
  • Set the AutoLoad process frequency (default is 15 minutes).
    “TIME_INTERVAL_MINUTES=[Your-Value]” in the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/schedule.[sh|bat] file.
    Note: Reference the SAS Visual Analytics Administration Guide for more about  the timing of AutoLoad.
  • Schedule the AutoLoad process using the LASR Server administrator account responsible to manage this particular LASR Server by executing the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/schedule.[sh|bat] script.

Validate the AutoLoad setup by stopping the SAS LASR Server from SAS Visual Analytics Administrator application, or using SAS code. Wait for the “TIME_INTERVAL_MINUTES=[Your-Value]“, and look at the LASR Server status in SAS Visual Analytics Administrator application, and the AutoLoad logs in [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/Logs (one log file each time the AutoLoad process is executed).

Whichever technique is used, the non-distributed LASR server will no longer be dependent on the middle-tier.

I hope this article has been helpful to you.

How LASR servers are started from SAS Visual Analytics Administrator was published on SAS Users.

Back to Top