Hello everyone!   SAS Education is pleased to announce a large addition to the course: Managing Users, Settings, Content Delivery, and REST APIs in SAS Customer Intelligence 360.   This course is available in the Customer Intelligence Learning subscription and is intended for developers and administrators.   The following lesson and topics have been added:   Lesson 4:  REST APIs of Customer Intelligence 360 Getting Started Managing Data Managing Marketing Objects Automating Marketing Campaigns Administer and Configure the Environment   These sections include information and demonstrations on obtaining authentication and making API requests.   ... View more

This article will discuss a newly added feature of SAS Visual Investigator: data masking. Keep reading to learn how you can leverage this feature to protect sensitive information in your Visual Investigator environment.   In this example, we'll be looking at an external data object Customer, representing customer data stored externally to Visual Investigator. Thus, data for the instances of this entity cannot be changed in Visual Investigator. However, Visual Investigator administrators can configure entity definitions to determine which data is displayed, and protect sensitive fields and information.   Here is an example of the Customer entity as it is currently configured. This page appears the same way in the user interface to an administrator, a manager, and an analyst. This is the view context.    Appearance of the Customer page to all users before data masking is applied.   The tax ID field in this case represents the social security number for the customer instance. Let's configure this entity so that this sensitive information is masked.   I switch back to my administrative interface - Manage Investigate and Search. I choose Data Objects on the menu bar. I double click the Customer entity to open it.   I navigate to the Fields tab of the entity and review the available fields.    Configuring the fields of the Customer entity   On this tab, I can add or remove entity fields to determine what is accessible in Visual Investigator. I can configure details abot the fields, including how they are indexed, whether each field is required, etc.   In this case, I click the Party Tax Id field to open the field properties.   I check the box next to Data Masking. There are a few things to consider when masking data. I click the warning icon next to the option to display a popup indicating some of these considerations.    Masking the Party Tax Id field   For example, you cannot create conditions on masked fields, and if you mask a field that is utilized in existing conditions, it might impact them. In this environment, I don't have any conditions, object labels, or other features configured to use this field, so I'll continue.    Selecting the groups with permission to unmask the data   I click the users icon next to "Authorized to reveal masked data". I choose sviadms (Visual Investigator Administrators), and click OK.   Now, only users in the administrators group will be able to unmask this field.   I click OK again, and then save the entity. I click the More icon and then select Re-index this entity so that the changes can take effect.   I'll finish by looking at the Customer page in the Investigate and Search interface again.   First, I'll remain signed in as my administrator. I search "James" and review the search results. The Tax ID field has been obscured.    The Tax ID field is masked in the search results.   I click James Hurst to open the entity page. This page also has the Tax ID field obscured.    Masked data on the Customer page. Clicking the eye icon unmasks the data.   I click the eye icon to unmask the data.    the unmasked Tax Id field   In this case, I am signed in as an administrator, which we have authorized to unmask this field.   This is how the page appears to another user who is not in the Administrators group:     Now, the Tax ID field has been restricted for all Customer entities to only Administrator users. This is just one way that you can configure your Visual Investigator environment for your needs. For more information on configuring data masking and other settings and properties of Data Objects, see the Visual Investigator Administrator's Guide.   ... View more

In this blog, you'll learn how to use the Discover download program and the Marketing Gateway API to download data tables from SAS Customer Intelligence 360. We'll discuss how to obtain, configure, and use the program.   The Marketing Gateway API is one of the SAS Customer Intelligence 360 REST APIs. Using these endpoints, a program or user can download detail tables, discover base tables, metadata tables, and more. You can read more about the APIs in this introductory post or the REST API documentation.   To simplify using the Marketing Gateway API and processing the response, you can utilize the Discover Download program. This program can handle the required setup for the API, submit requests, and even process the response for you. The discover download program is available on Github either using python or a combination of python and SAS.   In this brief demo of the program's functionality, we will be using the python version, available here.   Once it is configured, the discover download program is a simple and more human-readable way to use the Marketing Gateway collection to download data tables.   The program generates the static JWT, submits the REST request on your behalf, and then processes the response automatically. In this example, we will download detail tables as CSV files.   I'll start by ensuring I have an access point and note its client secret, as well as the tenant ID and external gateway address of the tenant I'd like to use.   I start by cloning or downloading the program from GitHub. I'll add the tenant information to the config file in the dscconfig directory of the downloaded client. I copy and paste the tenant ID, client secret, and external gateway address into the corresponding variables tenantID, secret, and baseUrl.   I leave the agentName value the same.   Next, I'll open a command prompt and navigate to the extracted folder containing the discover.py file. I verify the client is set up with the command   python3 discover.py -h   This command specifies to run the discover download program using Python 3. The -h help option prints a list of the other options you can use to configure your download.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   If it is your first time running the discover download program, you may discover that you need to install some dependencies, which will be identified the first time you try to run the program. For example, you can download the required tqdm package using:   pip install tqdm   Once I've installed any required packages and verified that the discover program is working with the help option, I can run the program again with several options to download the detail tables.   Now I'll add several commands to specify information about the tables I want to download. I add the -st and -et options to specify the START and END datetimes. This range is from midnight on the first until midnight on the third of December, 2023. I enter the option -cf yes to specify I want the results as a CSV file. Lastly, I enter the -cd option, then “,”, to specify that I want to use a comma in my CSV file.   The full command with all options now reads:   python3 discover.py -m detail -st 2023-12-01T00 -et 2023-12-03T00 -cf yes -cd "," I enter the command, and wait for it to finish running. Then I return to the discover program directory, and check the discover data warehouse (dscwh) directory for the CSV files from my download.   This is just a short introduction and preview to the functionality of the Marketing Gateway API and the Discover Download program. For more information about these resources including examples, see the program repository and the API documentation. ... View more

In this post, we’ll introduce the Customer Intelligence 360 REST APIs and demonstrate how to get started using them, including submitting your first API call using Postman.   REST APIs 101   What is a REST API?   The APIs we will discuss here adhere to a set of defined requirements called REST, or Representational State Transfer. REST API calls consist of HTTP requests that can be submitted programmatically in a script, or submitted manually as we will be doing in this example.   RESTful APIs use calls submitted via a URL with one of the primary HTTP methods: Post, Get, Put, Patch, and Delete. When a client submits one of these methods and the associated data to a server, they are making a request.   The server, which in this case is Customer Intelligence 360, issues a response that includes the requested information or an error indicating what went wrong. The response may be formatted as JSON, XML, or an image.     Another characteristic of REST APIs is that all the information required to fulfill the request must be included in the request itself.   Figure 1: a client submits a request with an authentication token and the server provides a corresponding response.  Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   What are the CI Rest APIs?   Customer Intelligence 360 can be integrated with on-premises and cloud-based data, channels, and services in a variety of ways. One of those ways is by providing REST APIs for managing data, tasks, segments, and other assets.   In this example, we will use the marketing gateway API to request the configuration information for an access point. Other endpoints of this API enable users or programs to download data tables and the agent zip files, inject external events, and more. For a complete list of the CI360 REST APIs and more information on their endpoints and functions, refer to the REST API documentation.   What is Postman, how do I use it? What other tools do I need?   We will be using Postman, a client enabling REST requests to be sent from the desktop to the CI360 gateway.   If you would like to try this example yourself, you can download the desktop client or access the browser version of Postman.   You’ll also need to install python and the python library PyJWT in order to run the script to generate a token to authenticate your request.   Where can I find more information?   For more information on the REST APIs of Customer Intelligence 360, see the developer’s site and documentation, product documentation, and SAS Communities.   Getting started   Authenticating REST requests   Setting up to use the REST APIs is simple, and you will only need to complete the initial steps once or infrequently. Then you can begin submitting REST API calls. These steps are setting up the external gateway, creating API credentials, and setting up authentication.   The REST APIs are secured using bearer token authentication. Different token types can be utilized to access Customer Intelligence 360 from the APIs depending on their security needs.   Requests to the Customer Intelligence 360 APIs can be authenticated in three different ways: a static JWT (JSON Web Token), a temporary JWT, and an access token.   A static JWT does not expire and can be generated programmatically using a tenant ID and a client secret associated with an access point.  It is only invalidated if the access point used to create it is deleted or deactivated. This is the authentication method we will use in this example to access the Marketing Gateway API.   For more information on token types and generating and managing tokens for authenticating REST requests, see the token management section of the documentation.   We'll start by creating or utilizing an existing access point. We also need to take note of the external gateway host. These steps are completed in the Customer Intelligence 360 user interface in the general settings.     Figure 2: Under General Settings > External Access > Access Points, you can manage and create access points and their credentials.   I select Access Points under External Access and review my table of access points. At this point, I can either select the New Access Point icon to create a new general access point, or select an existing one from the table. If your environment has a general access point already configured, you can use the same general access point for the general agent, API requests, and other integrations.   I click General Access Point to pull up the access point credentials. I’ll use these credentials along with the external gateway address to customize and authenticate my API request.   Next, I need to create A JWT to be included with the calls for authentication. This can be done in Postman, or in the Customer Intelligence User Interface*. A JSON Web token is a bearer token that is put in the header of the API request to authenticate the client (POSTMAN or a script on an on-premises machine, etc.) with the CI 360 server.   There are several ways to generate the static JWT, but in this example we will be using a python script that utilizes the PyJWT library. Here is the code:   import base64 import jwt tenantId = '00001ae00001' secret = 'MkiasdfasdfsadfsadfsdafsHSF98575' encodedSecret = base64.b64encode(bytes(secret, 'utf-8')) token = jwt.encode({'clientID': tenantId}, encodedSecret, algorithm='HS256') print('\nJWT token: ', token)   I only need to adjust the tenant ID and client secret in this script. I save and run this script in the command line. The result is a JWT, which I note. This JWT will remain active unless I delete the access point used to generate it or replace its credentials.   C:\Users\sasdemo> python generateCIstaticJWT.py JWT token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjbGllbnRJRCI6ImY2NzJjZDI5ODIwMDAxMDdmN2M2MzdmOCJ9.16uHULoaTv7VYhRewbcObqHQ36b9dHD3bZ0qZgY-QRSTUVWXYZ   Downloading the collection of API calls   Now, we'll download the collection to Postman before adjusting the calls to our specific environment. This is not required to submit the API calls, but it saves time and makes it easier to correctly format the requests because the collection acts as a template.    I begin on developer.sas.com and select CI360, then choose Get Started with APIs. Clicking ‘View the entire set of REST API Documentation’ will take me to the API section of the product documentation.   Figure 3: Landing page shown after selecting SAS Customer Intelligence 360 on developer.sas.com   Instead, I scroll down to the list of APIs and select Marketing Events Gateway. This directs me support.sas.com and additional API-specific documentation, including examples.   Next, I’ll download the collections from this documentation. I click Download next to Download Open API Specification.      Figure 4: After navigating to the Marketing Gateway developer documentation, I click Download to download the collection.   Now, I open postman. I create a new collection by clicking Import, and importing the collection I just downloaded.     Figure 5: Importing the collection from the download file   Modifying the collection for my environment   Now, I’ll modify this collection as needed to submit the calls to my specific tenant. I click the Marketing Gateway API collection in the right side bar, then select Variables on the right.   I edit the base URL of the collection and paste in my external gateway address from the Access Points page in the UI. In this case, it is extapigwservice-training.ci360.sas.com.     Figure 6: Modifying the base url of the collection   The base URL should now match the external gateway address I saw earlier under Access Points in the user interface, with the appended ‘root’ /marketingGateway.   Next, I’ll navigate to the Authorization tab. I select Bearer Token from the Type drop down. I enter the response from the python script I ran earlier.     Figure 7: Provide the JWT as the collection authentication   I click save in the top right to save both of these changes to my collection. Now, the calls in the collection will use the base URL corresponding to my tenant’s external gateway address, and inherit the authentication information I’ve specified here. This saves me the time of supplying the authentication with each call.   Let’s test our REST request   Now, we are ready to test the API configuration by submitting a call to the Marketing Gateway API. I will be submitting a request to query the API/access point configuration.   Under Marketing Gateway API in the left navigation pane, I expand the configuration folder and click the GET request “Get the configuration for the API”.   I review the authorization tab, verifying the call will inherit authorization information from its parent in the form of the bearer token we added earlier.   If desired, I can click the code icon to display the call as a code snippet instead of the form-like view where we enter each field in Postman     Figure 8: After selecting a call from the collection you can verify the authorization header inheritance and view the request as a formatted code snippet.   This is particularly helpful when comparing calls you are testing against the examples in the documentation, many of which are formatted as cURL snippets.   When I am ready to submit the request, I click Send and view the response. I get a 200 response – the standard HTTP response indicating my GET request has been successful. I can review the access point information in the response and toggle between raw and formatted JSON.     Figure 9: Formatted response JSON after a successful request   This example is just a small taste of the functionality available from the Customer Intelligence 360 REST APIs. For example, this post discusses how to use the Marketing Data API to GDPR delete identity data.   For more information on the APIs, their use cases, and additional examples, see the documentation and communities.     Find more articles from SAS Global Enablement and Learning here. ... View more

Visual Investigator is a versatile solution enabling customized configuration of a user interface to support investigations in various sectors including insurance, law enforcement, and banking. Little or no code is required to configure and use the solution. For developers, the REST APIs of Visual Investigator can be utilized to manually or programmatically interact with data outside of the interfaces. They are also used to integrate external applications with Visual Investigator.   In this blog, we’ll broadly introduce the REST APIs for SAS Visual Investigator and discuss where to find more information. We’ll look at a datastore configuration in the administrative interface. Finally, we will use an API call to retrieve the data store information. We’ll submit this call using Postman, a free API tool available for download.   Resources   The SAS for Developers site is an excellent place to begin when looking for information on the APIs and other development resources.    The homepage of developer.sas.com   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   We can filter by solution to navigate to the Visual Investigator-specific developers site. Two sets of API documentation are linked here.    Visual Investigator developer documentation links   This page includes links to the documentation for the REST APIs , client APIs, and other documentation and support resources for Visual Investigator. Today, we’re talking about basic setup for the REST APIs, so we’ll click the navy tile to navigate to the Visual Investigator REST API documentation. These APIs enable administrators to submit REST calls to Visual Investigator to interact with data and other resources through various endpoints.   This documentation includes a glossary and description of the Datahub API and its endpoints. For this example call, I would like to use the /admin/dataStores endpoint and the GET method to retrieve the information for a datastore.   On the right is the navigation sidebar. To the right of the documentation text, I can see code examples including requests and responses.    Visual Investigator REST API Documentation   There are many other endpoints of the Datahub API than discussed here described in this documentation. They enable the access and manipulation of Visual Investigator data on the back end. This is the best practice method for acting on these entities outside of the interface. It is preferred over attempting to modify elements of the data in the database or elsewhere.   But before we can dive into using the REST APIs, there are a few one-time initial setup steps required.   Initial Setup   First, I modify the hosts file on my local computer to include the following:   XX.XX.XX.XX client.demo.sas.com XX.XX.XX.XX server.demo.sas.com tenant1.server.demo.sas.com tenant2.server.demo.sas.com tenant3.server.demo.sas.com tenant4.server.demo.sas.com   I change the IP addresses to the windows client and linux server IPs corresponding to my reservation instance, and also modify the tenant names and server names as needed. I save my changes. This step can be skipped if working on the client machine itself, but since I am using a RACE image, I need it so that POSTMAN can know which specific client and server are being referenced by the calls using the simple tenant and server name.   The next step is to generate a token so that the calls to the API can be authenticated. I’ve created a new collection and called it VI_API_Demo. I click the Authorization tab. I’ll be using Postman to generate and automatically include a token in the header of each call. I select OAuth 2.0 as the type, and ensure that the collection is configured to automatically send this information in the header of the request rather than the query parameters.   I’ll call my token vi_auth_token, and for Grant type, I’ll select Password Credentials.   Note: This example uses a Visual Investigator 10.8 environment. Steps may vary slightly depending on the Visual Investigator Environment and method of interacting with the API. After 10.8, the authentication changed and this grant type is no longer permitted to pass the user and password pair when obtaining the authorization token.   For the Access Token URL, I enter the URL I would access my tenant at, followed by /SASLogon/oauth/token:   https://tenant1.server.demo.sas.com/SASLogon/oauth/token   I enter sas.client for the client ID, and leave the client secret blank. I use admin and Student1 as the password. I click Get New Access Token, then Proceed and finally Use Access token to activate the token for the collection.   Retrieving Data Store Configuration   This is how the data store looks in the administrative interface, in the Properties Tab under Data Stores:    Data store configuration information in the user interface   Now, we will test that our configuration is working, and send our first call to the Datahub API to view the data store information a different way.   I copy the example code shown on the API Documentation page   curl -X GET https://example.com/svi-datahub/admin/dataStores?name=string \ -H 'Authorization: Bearer ' \ -H 'Accept: application/json'   Next, I modify the call to use my specific server and tenant name. We also delete the Authorization line in the command, but this can also be done in Postman by unchecking that value in the Header. It is not necessary since we already configured an authentication token for Postman.   curl -X GET https://tenant1.server.demo.sas.com/svi-datahub/admin/dataStores?name=insurance \   -H 'Accept: application/json' I click Import and paste the command to import the call to Postman.   Under authorization, I ensure that the call inherits authorization from the parent collection. Now the authorization header will automatically include the token we generated earlier.   I save the call under the collection, and submit it. Then I examine the response in Postman and compare it to the information from the Manage Investigate and Search interface.    JSON response querying data stores named insurance   For example, in lines 9-13, I can see the database type, schema name, port, server and additional URL parameters configured with the database.   The response verifies that Postman has successfully delivered the request to Visual Investigator and my tenant is configured as expected. This authorization token can be reused in other calls to Visual Investigator before it eventually expires.   For example, if I didn’t know the name of the data store, I could submit a different call to return all the data stores:   curl -X GET https://tenant1.server.demo.sas.com /svi-datahub/admin/dataStores/all?includeInternal=false \   -H 'Accept: application/json'   As long as this call inherits the token we created earlier, I can omit the Authorization header in the call syntax, as seen on in the documentation code examples.   This is just a small preview of the functionality of the REST APIs of Visual Investigator, so be sure to explore the documentation and community for more information on using these tools to administer and manage your own Visual Investigator environments.   Find more articles from SAS Global Enablement and Learning here. ... View more

Hello!   SAS Education has released a major update for the course SAS 360 Engage: Administration and Settings! This update provides new and revised content on several lessons in this course.      SAS CI360 Learning Subscription website: https://www.sas.com/en_us/training/programs/customer-intelligence-360-learning-subscription.html ... View more